Best practice zu Dateiberechtigungen (gelöst) - #191691 (Allgemeines zu Perl)

haj

2020-04-03 20:23

User since
2015-01-07
562 Artikel
BenutzerIn

user image

2020-04-03T07:39:45 bianca
Was ist best practice im Umgang mit den Dateiberechtigungen bei sysopen() und mkdir() auf Linux und Windows?

Da gleich mal eine Warnung: Linux und Windows sind völlig verschieden, und es hängt auch noch vom verwendeten Dateisystem ab. Über Windows nur soviel: Es gibt Perl-Module zum Steuern der Zugriffsrechte wie CPAN:

Win32::FileSecurity, aber wenn Du nicht schon mit anderen Windows-APIs sowas bearbeitet hast, dann wird Dir deren knappe Dokumentation wohl kaum ausreichen.

2020-04-03T07:39:45 bianca
Ich komme mit diesen oktalen Werten immer nicht nicht richtig zurecht. Besonders nicht mit Setuid, Setgid und Sticky Bit.

Das kann ich nachvollziehen. Für mich waren Oktalzahlen schon immer ziemlich hoch auf der Nerdometer-Skala, insbesondere die Schreibweise mit der führenden Null.

2020-04-03T07:39:45 bianca
Verstanden habe ich deren Bedeutung aber die Syntax bereitet Probleme.
Gibt es vielleicht ein Core Modul oder ähnliches wo ich quasi die Kreuzchen setze und den richtigen Wert zur direkten Verwendung in sysopen() zurück bekomme? Also z. B. sowas wie sysopen my $dh,$dn,O_RDWR|O_EXCL|O_CREAT,berechtigung('rwxrwsr-x')?

Nicht ganz in dieser Weise, aber analog zu O_RDWR kann man - ebenfalls mit CPAN:

Fcntl - mysteriöse benannte Konstanten verwenden. Diese Konstanten importierst Du mit use Fcntl qw/:mode/; und Du kannst sie dann für den ganzen Zirkus der Funktionen verwenden.

Auch hier gleich ein Hinweis: Unter Windows gibt's weniger Konstanten als unter Linux, und sie funktionieren auch nur sehr eingeschränkt. Die ganze MODE-Logik ist eine Unix-Erfindung - und da kommt Perl nun mal her.

Die Konstanten sind nun nicht wirklich in Perl dokumentiert (bei chmod gibt es ein Beispiel), deswegen habe ich mal ein Programm geschrieben, das sie zusammen mit ihren Oktalwerten ausgibt:

Code (perl): (dl )

use Fcntl;
my @constants = grep { /^S_I/ && eval { Fcntl->$_ } } keys %Fcntl::;
my %values    = map { $_ => Fcntl->$_ } @constants;
for (sort { $values{$a} <=> $values {$b} } keys %values) {
    printf "%-8s = %07o\n", $_, $values{$_};
}

Die Ausgabe beginnt nun mit folgenden Werten:

Code: (dl )

S_IXOTH  = 0000001
S_IWOTH  = 0000002
S_IROTH  = 0000004
S_IRWXO  = 0000007
S_IXGRP  = 0000010
S_IWGRP  = 0000020
S_IRGRP  = 0000040
S_IRWXG  = 0000070
S_IEXEC  = 0000100
S_IXUSR  = 0000100
S_IWRITE = 0000200
S_IWUSR  = 0000200
S_IRUSR  = 0000400
S_IREAD  = 0000400
S_IRWXU  = 0000700
S_ISGID  = 0002000
S_ISUID  = 0004000

Alle fangen mit S_I an, danach kommt (meistens) der Buchstabe, um welches Recht es sich handelt (R, W, X), und danach USR für den Benutzer, GRP für die Gruppe, und OTH für den Rest der Welt. Daneben gibt's noch die mit RWX als Abkürzungen.

Ein Anwendungsbeispiel: berechtigung('rwxrwsr-x') kannst Du schreiben als S_IRWXU | S_IRWXG | S_IROTH | S_XOTH | S_ISGID. Und dazu nochmal eine Warnung: S_ISGID (setgid) tut bei Perl-Skripten nicht das, was Du vielleicht erwartest. Das liegt daran, dass das ausführbare Programm /usr/bin/perl ist, Dein Skript ist nur eine Input-Datei dafür. Da müsste also Dein Provider für jeden seiner Kunden einen kleinen binären Wrapper schreiben, der dann dem jeweiligen Kunden gehört und das S-bit trägt. Es gab Provider, die haben das so gemacht - aber Dein Perl-Skript braucht das Bit auch in diesem Fall nicht.

Dass Du Deine Dateien so restriktiv wie möglich einstellen willst, ist Teil der Best Practice in einer Umgebung, in der Sicherheit eine Rolle spielt. Aber auch das hängt davon ab, wie Dein Provider sein Shared Hosting anbietet. Sicheres Shared Hosting mit CGI ist ja schon etwas anspruchsvoll, wenn die einzelnen Nutzer eines Apache Virtual Host (oder was auch immer als Webserver eingesetzt wird) voneinander einigermaßen abgeschottet werden sollen. Wenn da z.B. Wikipedia:

FastCGI läuft, kann jeder Kunde seinen eigenen CGI-Prozess haben, der unter seiner eigenen Benutzerkennung läuft.

Dass für eine sinnvolle Einstellung umask eine Rolle spielt, hat ja Raubtier schon erläutert. umask schaltet bei allen erzeugten Objekten die angegebenen Zugriffsrechte aus ("maskiert" sie). Wichtig ist, das umask als Perl-Funktion verfügbar ist und somit für alle Dateien und Verzeichnisse gilt, die der Prozess danach (bis zur nächsten Änderung der Umask) anlegt. Mit umask S_IRWXG | S_IRWXO kannst Du sicherstellen, dass neu angelegte Dateien und Verzeichnisse nur von Deiner eigenen Benutzerkennung gelesen und geschrieben werden können. Auch der MODE, den Du bei sysopen und mkdir angeben kannst, wird damit noch eingeschränkt! Unabhängig von der umask kannst Du die Zugriffsrechte nur nachträglich mit chmod ändern.

Nun kann man sich mit diesen Funktionen prima selbst ein Bein stellen. Wenn Du Software schreibst, die unter unterschiedlichen Hosting-Szenarien läuft, dann sollte die umask-Einstellung konfigurierbar sein. Ob Du zusätzlich noch eine Konfigurationsdatei mit individuellen Einstellungen pro Datei brauchst, musst Du selbst beurteilen, aber eben dabei berücksichtigen, dass umask auch auf sysopen und mkdir wirkt.