Userrechte

[Maxwell]

Hallo,

ich habe ein merkwürdiges Problem bei Perl mit Benutzerrechten:

Wenn ich in Perl eine Datei über:

open( F, '>./998' );
print F ...;
close(F);

anlege. Woher nimmt er die Info, welche Rechte diese Datei haben soll?

Ich habe z.B. den Output:

-rwxr-xr-x 2 domain psacln 4096 Nov  4  2006 998
-rwx------ 2 domain psacln 4096 Nov  4  2006 999

Beide Dateien wurden über denselben Aufruf open-print-close erstellt. Beide aus dem Webserver mit CGI-Schnittstelle. Aber warum hat die eine Datei weniger Rechte, als die andere. Woher kann das kommen?

Hat das etwas mit umask zu tun?

Grüsse,

Maxwell

[Horst]

Hallo,

Hat das etwas mit umask zu tun?

Ja, schon. Aber welcher Serverbetreiber ist so deppisch ein umask 022 zu setzen, womit jede über Webupload neu angelegte Datei ausführbar ist? Das ist ja ein höllisches Sicherheitsloch.

Viele Grüße,
Hotte

[Maxwell]

Hallo Hotte,

Hat das etwas mit umask zu tun?
Ja, schon. Aber welcher Serverbetreiber ist so deppisch ein umask 022 zu setzen, womit jede über Webupload neu angelegte Datei ausführbar ist? Das ist ja ein höllisches Sicherheitsloch.

Also irgendwie spielt die eh verrückt, ansonsten würden die beiden Dateien doch stets die selben Rechte erhalten, oder???

Grüsse,

Maxwell

[Horst]

Hallo,

Also irgendwie spielt die eh verrückt, ansonsten würden die beiden Dateien doch stets die selben Rechte erhalten, oder???

Nunja, Linux ist halt ein Multi-User-OS. Evntl. schwirrt da noch einer rum auf der Kiste!? Evntl. einer der nicht sein darf, da...

Anders kann ich mir das auch nicht erklären was da los ist.

Viele Grüße,
Hotte

[Tom]

Hello,

Also irgendwie spielt die eh verrückt, ansonsten würden die beiden Dateien doch stets die selben Rechte erhalten, oder???

Nicht unbedingt.
Es kann davon abhängen, wer das Script aufruft.

Welche Rechte werden denn für das Script angezeigt?

Wenn das SUID-Bit gesetzt ist, dann wird das Programm unter den Rechten des Owners ausgeführt
Wenn das SGID-Bit gesetzt ist, dann wird das Programm unter der Gruppe ausgeführt, zu der es gehört

Soweit ich das verstanden habe, haben die dann auch jeweils ihre eigene umask

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Christian Seiler]

Hallo Tom,

Also irgendwie spielt die eh verrückt, ansonsten würden die beiden Dateien doch stets die selben Rechte erhalten, oder???

Nicht unbedingt.
Es kann davon abhängen, wer das Script aufruft.

Nein, zumindest nicht direkt. Die umask ist eine Eigenschaft, die unabhängig von der Benutzer- und Gruppenzugehörigkeit eines Prozesses gilt. Dass ein anderer Benutzer evtl. eine andere Default-Umask gesetzt hat, mag da mit rein spielen, ist aber hier im Webkontext irrelevant.

Wenn das SUID-Bit gesetzt ist, dann wird das Programm unter den Rechten des Owners ausgeführt
Wenn das SGID-Bit gesetzt ist, dann wird das Programm unter der Gruppe ausgeführt, zu der es gehört

Das ist in der pauschalen Form nicht richtig. Bei gesetztem SUID-Bit wird die effektive Benutzer-ID eines Prozesses auf die des Dateieigentümers gesetzt, bei gesetztem SGID-Bit wird die Gruppen-ID eines Prozesses auf die der Gruppe, der die Datei gehört, gesetzt. Mehr kann man erstmal nicht sagen und wie genau das dann mit den tatsächlichen Rechten eines Prozesses zusammenhängt, liest man am besten im Stevens nach. Zudem hat SUID und SGID mit dem Thema hier nichts (!) zu tun.

Soweit ich das verstanden habe, haben die dann auch jeweils ihre eigene umask

Die Umask ist eine Eigenschaft des Prozesses, die UNABHÄNGIG von Benutzer- und Gruppenzugehörigkeit gilt. Die genaue Erklärung, WAS sie macht, hat Sven schon geliefert.

Viele Grüße,
Christian

[Tom]

Hello,

Wenn das SUID-Bit gesetzt ist, dann wird das Programm unter den Rechten des Owners ausgeführt
Wenn das SGID-Bit gesetzt ist, dann wird das Programm unter der Gruppe ausgeführt, zu der es gehört

Das ist in der pauschalen Form nicht richtig. Bei gesetztem SUID-Bit wird die effektive Benutzer-ID eines Prozesses auf die des Dateieigentümers gesetzt, bei gesetztem SGID-Bit wird die Gruppen-ID eines Prozesses auf die der Gruppe, der die Datei gehört, gesetzt. Mehr kann man erstmal nicht sagen und wie genau das dann mit den tatsächlichen Rechten eines Prozesses zusammenhängt, liest man am besten im Stevens nach. Zudem hat SUID und SGID mit dem Thema hier nichts (!) zu tun.

Den Stevens habe ich leider nicht und wenn er gut sit, dann ärgere ich mich jetzt, dass ich nmir dieses Jahr kein gutes Buch mehr leisten kann.
Wasa schreibt er denn über die SUID?

Was ich nirgends gefunden habe, was ist denn, wenn beide gesetzt sind? Oder ist das nicht möglich? Aber ist doch ein Bitflag?

Soweit ich das verstanden habe, haben die dann auch jeweils ihre eigene umask

Die Umask ist eine Eigenschaft des Prozesses, die UNABHÄNGIG von Benutzer- und Gruppenzugehörigkeit gilt. Die genaue Erklärung, WAS sie macht, hat Sven schon geliefert.

Ich habe mir das auch so vorgestellt, dass das Script (also eigentlich der Prozess) die effektive UID kennen könnte und daher darauf reagieren könnte. Denn die dritte Variante wäre ja, dass der Prozess unter der UID des "normalen" Aufrufers läuft.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Christian Seiler]

Hallo,

Den Stevens habe ich leider nicht und wenn er gut sit,

Stevens, Rago, "Advanced Programming in the UNIX environment" ist IMHO _DAS_ Standardwerk bezüglich Systemprogrammierung unter UNIX.

Wasa schreibt er denn über die SUID?

Ich schreibe das doch jetzt nicht alles ab...?

Leih' ihn Dir doch aus, da Du ja m.W. aus der Ecke Braunschweig kommst, kannst Du Dir in der Universitätsbibliothek Braunschweig das Buch einfach ausleihen (m.W. kann man sich als Einwohner des betreffenden Bundeslandes einen Ausweis für jede Universitätsbibliothek holen, auch wenn man nicht dort studiert).

Was ich nirgends gefunden habe, was ist denn, wenn beide gesetzt sind?

Es passiert einfach beides - so what?

Die Umask ist eine Eigenschaft des Prozesses, die UNABHÄNGIG von Benutzer- und Gruppenzugehörigkeit gilt. Die genaue Erklärung, WAS sie macht, hat Sven schon geliefert.

Ich habe mir das auch so vorgestellt, dass das Script (also eigentlich der Prozess) die effektive UID kennen könnte und daher darauf reagieren könnte. Denn die dritte Variante wäre ja, dass der Prozess unter der UID des "normalen" Aufrufers läuft.

Und was bitteschön hat das jetzt mit Umask zu tun?

Viele Grüße,
Christian

[Christian Seiler]

Hallo,

Also irgendwie spielt die eh verrückt, ansonsten würden die beiden Dateien doch stets die selben Rechte erhalten, oder???

Nein, die umask spielt nicht verrükt, allerdings ist die umask nicht für den Webkontext gedacht worden. Wenn man jetzt Dinge direkt im Kontext des Webservers ausführt, wie z.B. über mod_perl, mod_php oder mod_python möglich, dann kann es sein, dass ein Script die umask des Webservers ändert. Dann gilt die geänderte umask für alle weiteren Scripte BIS DIESE die umask umsetzen.

Daher ist es sinnvoll, in eigenen Web-Scripten am Anfang explizit die umask zu setzen, die man haben will. In der Regel dürfte das sowas wie 022 sein, kann aber auch 0 sein.

Viele Grüße,
Christian

[Tom]

Hello,

Daher ist es sinnvoll, in eigenen Web-Scripten am Anfang explizit die umask zu setzen, die man haben will. In der Regel dürfte das sowas wie 022 sein, kann aber auch 0 sein.

Bitte nicht gleich wieder schlagen ;-)
Ich ahbe da schon seit Tagen eine Frae zu dem Thema, aber erstmla immer wieder nebenbei danach im Web gesucht. Ist aber nicht wirklich etwas zu finden gewesen, bzw. ich kann es vielleicht nicht deuten.

Wenn ich mit chmod() in PHP die Rechte ändere, dann werden die Rechte oktal angegeben.
Wenn ich das gleiche in der bash tue, ist es nicht anders.
Wenn ich nun statt "0644" "04644" schreibe, dann wird in der bash das SUID-Flag gesetzt. Das wollte ich damit auch erreichen.
Wenn ich das Gleiche aber in PHPs chmod() mache, ergibt das "ulkige" Ergebnisse. Ich wollte nun gerne in den Quellcode gucken, waurm das so sein könnte. Leider weiß ich nicht, wo der zu chmod() verdrahtet steht und wahrscheinlich hätte ich esowieso nichtr verstanden. Was macht PHP da? Die "ulkigen Ergebnisse" bekommt man auch mit "2664" oder "4664", aber eben nicht mit "0664".

Wird nur eine dreistellige Ziffernkolonne in den oktalen Wert überstzt vom Parser und bei einer vierstelligen z.B. eine Hexadezimale oder dezimale?

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[dedlfix]

echo $begrüßung;

Wenn ich mit chmod() in PHP die Rechte ändere, dann werden die Rechte oktal angegeben.

Die Funktion möchte ein Integer-Argument haben. Notfalls kommt hier die automatische Typumwandlung PHPs zum Tragen. Du kannst unter Beachtung der PHP-Eigenheiten angeben, was du willst. Wenn du allerdings die oft verwendeten Oktalwerte nutzen willst, musst du sie auch PHP-gerecht notieren, nämlich mit einer 0 vorndran.
http://de2.php.net/manual/en/language.types.integer.php

Wenn ich das gleiche in der bash tue, ist es nicht anders.

chmod in der bash ist anders. Hier arbeitet kein PHP dazwischen, das das Argument schon vorher mal interpretiert und eine Oktalzahl erkennt oder auch nicht.

Wenn ich nun statt "0644" "04644" schreibe, dann wird in der bash das SUID-Flag gesetzt. Das wollte ich damit auch erreichen.
Wenn ich das Gleiche aber in PHPs chmod() mache, ergibt das "ulkige" Ergebnisse.

Dann nimm doch nicht "04644" sondern 04644.

Ich wollte nun gerne in den Quellcode gucken, waurm das so sein könnte. Leider weiß ich nicht, wo der zu chmod() verdrahtet steht und wahrscheinlich hätte ich esowieso nichtr verstanden.

cvs.php.net -> php_src -> ext -> wenn keine spezielle zu finden ist, dann: standard -> file.c Fehlanzeige, filestat.c, derzeit ab Zeile 592.

Was macht PHP da? Die "ulkigen Ergebnisse" bekommt man auch mit "2664" oder "4664", aber eben nicht mit "0664".

Sind ja auch keine Oktalzahlen (müssen mit 0 anfangen), und als String hast du sie hier auch zitiert. Kann natürlich sein, dass du sie zur besonderen Hervorhebung in "" eingerahmt hast, aber im PHP-Quelltext ergibt das eine andere Wirkungsweise als z.B. als Argument in der bash.

echo "$verabschiedung $name";

[Tom]

Hello,

Dann nimm doch nicht "04644" sondern 04644.

Hab ich doch. Liefert trotzdem bunte Ergebnisse.
Wie erkennt PHP denn nun, ob es eine Oktalzahl sein soll, oder eine Dezimalzahl?

Meine Versuche haben sich doch lediglich in der Anzahl der Digits unterschieden.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[dedlfix]

echo $begrüßung;

Dann nimm doch nicht "04644" sondern 04644.
Hab ich doch. Liefert trotzdem bunte Ergebnisse.
Wie erkennt PHP denn nun, ob es eine Oktalzahl sein soll, oder eine Dezimalzahl?

Hab ich doch verlinkt gehabt. Führende 0 und ohne nachfolgendes x, das Ganze noch außerhalb von Strings ergibt eine Oktalzahl. In RegExp ausgedrückt: 0[0-7]+

Meine Versuche haben sich doch lediglich in der Anzahl der Digits unterschieden.

Konnte ich nicht nachvollziehen. chmod('delinquent', 04644) ergibt -rwSr--r--

chmod('delinquent', 4644) und chmod('delinquent', "04644") ergibt hingegen den gleichen, nicht gewünschten Kokolores.

echo "$verabschiedung $name";

[Tom]

Hello,

Konnte ich nicht nachvollziehen. chmod('delinquent', 04644) ergibt -rwSr--r--

chmod('delinquent', 4644) und chmod('delinquent', "04644") ergibt hingegen den gleichen, nicht gewünschten Kokolores.

Merkwürdig.
Welche PHP-Version?

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[dedlfix]

echo $begrüßung;

Konnte ich nicht nachvollziehen. chmod('delinquent', 04644) ergibt -rwSr--r--
chmod('delinquent', 4644) und chmod('delinquent', "04644") ergibt hingegen den gleichen, nicht gewünschten Kokolores.
Merkwürdig.
Welche PHP-Version?

5.2.5

echo "$verabschiedung $name";

[Tom]

Hello,

Konnte ich nicht nachvollziehen. chmod('delinquent', 04644) ergibt -rwSr--r--
chmod('delinquent', 4644) und chmod('delinquent', "04644") ergibt hingegen den gleichen, nicht gewünschten Kokolores.
Merkwürdig.
Welche PHP-Version?

5.2.5

Ich werde das noch im Auge behalten.
Mal die neusten XAMPP-Versionen abwarten.
Bei Debian wird es wohl noch keine neues Package geben.
Ich habe noch das PHP 5.2.0-8+etch7 (cli) (built: Jul  2 2007 21:46:15)

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Sven Rautenberg]

Moin!

Hat das etwas mit umask zu tun?

Ja, schon. Aber welcher Serverbetreiber ist so deppisch ein umask 022 zu setzen, womit jede über Webupload neu angelegte Datei ausführbar ist? Das ist ja ein höllisches Sicherheitsloch.

Die umask definiert nicht, welche Rechte-Bits bei neuen Dateien gesetzt sind, sondern nur, welche garantiert gelöscht sind.

Die Defaultrechte neuer Dateien sind 0666, die neuer Verzeichnisse 0777 - darauf wirkt dann die umask.

- Sven Rautenberg