chmod

[Jörg Wittemeier]

Hallo !

Ich erzeuge per cgi ein Verzeichnis.

$permissions = 0777;
mkdir("$dirname",$permissions);

In dieses Verzeichnis erstelle ich eine Datei, auch via cgi.

open(LESEN,"$blank");
open(SCHREIBEN,"> $new");
while(defined($i = <LESEN>))
{
print SCHREIBEN $i
}
close(LESEN);
close(SCHREIBEN);

$permissions = 0777;
chmod($permissions,"$new");

Funktioniert soweit, doch wenn ich via FTP die neue Datei
umbennen oder löschen will habe ich kein Zugriff.

550 index.htm: Permission denied

chmod falsch gesetzt?

Gruß
Jörg

[Andrea]

Hi,

550 index.htm: Permission denied

chmod falsch gesetzt?

Ja.
Sollte 644 sein. Lesbar fuer alle, schreibbar fuer Dich.

Das ist so aufgebaut:
1. Zahl: owner - Du
2. Zahl: group - Alle, die zur selben Gruppe gehoeren. z.B. alle ENtwickler an einem Projekt
3. Zahl: other - Alle anderen.

Pro Gruppe gibt's folgende Rechte:
4 - lesen
2 - schreiben
1 - ausfuehren

Zum Setzen einfach zusammenrechnen.

Gruss,
Andrea

[Michael N.]

Hallo,

550 index.htm: Permission denied

chmod falsch gesetzt?

Ja.
Sollte 644 sein. Lesbar fuer alle, schreibbar fuer Dich.

Andrea, prinzipiell hast Du damit recht, aber ein Modus 777 (-rwxrwxrwx-) erlaubt ja auf jeden Fall jedwedem das Schreibrecht und somit muesste Joerg auch die Datei beschreiben, ueberschreiben und loeschen duerfen, egal ob sie unter seiner ID oder einer anderen ID erstellt wurde.
Ich selbst hatte mal ein aehnlich geartetes Problem unter einer UNIX-Umgebung, ich durfte kein "chown" an einen User derselben Gruppe auf Files machen, die mir gehoerten. Die Syntax meines Befehls war 100% korrekt, ich war Directory-Owner und File-Owner. Am Schluss stellte sich heraus: aus Sicherheitsgruenden war die Nutzung von "chown" für User nicht gestattet, chown durfte nur der Admin machen und der hat das dann ohne Probleme gemacht (mittels meines Befehls, den ich ihm gemailt hatte). Dann erst hat er recherchiert und als Ergebnis kam das oben gesagte raus.
Deswegen Joerg mein Rat: frag mal den System-Admin / SysOps, ob Du auf der Maschine das Recht hast, das Programm "chmod" auszufuehren, wenn Du dieses Recht nicht hast, frag, ob es moeglich ist es Dir zu geben, wenn keine Moeglichkeit dazu besteht, versuch es ueber "umask" (--> Betriebssystemdoku), dann werden alle Deine Files in dem betreffenden Modus gespeichert.

Bis danndann

Michael N.

[GONZO]

Deswegen Joerg mein Rat: frag mal den System-Admin / SysOps, ob Du auf der Maschine das Recht hast, das Programm "chmod" auszufuehren, wenn Du dieses Recht nicht hast, frag, ob es moeglich ist es Dir zu geben, wenn keine Moeglichkeit dazu besteht, versuch es ueber "umask" (--> Betriebssystemdoku), dann werden alle Deine Files in dem betreffenden Modus gespeichert.

Bevor du den Admin fragst, ob chmod geht, probiers doch selber mal kurz, indem du dir im FTP-Client die Dateirechte anguckst. (in ws-ftp glaubich mit dirlist)
Wenn die so sind, wie du sie dir eingestellt hast und auch owner und group stimmen, dann muß die Ursache noch woanders liegen. *Dann* kannst du ja mal den Admin "belästigen".

CYa
GONZO

[Jörg Wittemeier]

Bevor du den Admin fragst, ob chmod geht, probiers doch selber mal kurz, indem du dir im FTP-Client die Dateirechte anguckst. (in ws-ftp glaubich mit dirlist)

Hi !

Die DirectoryList zeigt in der Tat Merwürdiges:

drwxr-xr-x   2 65534    65534        1024 Jul 21 14:22 karl

wobei karl das neue Verzeichnis ist  :-)
alle anderen Dateien haben in der DirectoryListe statt der Zahl "65534" eine Teil aus meiner Pfadangabe stehen.

Außerdem sollte doch bei chmod 777 rwxrwxrwx stehen?

Tausend ?????

Gruß
Jörg

[Michael Schröpl]

Die DirectoryList zeigt in der Tat Merwürdiges:
drwxr-xr-x   2 65534    65534        1024 Jul 21 14:22 karl
wobei karl das neue Verzeichnis ist  :-)

Siehste wohl, mit guten Diagnosedaten kommen wir weiter.
"Dein" CGI-Skript wird nun mal nicht von *Dir* ausgeführt, sondern vom Webserver. Wenn es also ein Verzeichnis anlegt, dann gehört dieses Verzeichnis derjenigen Benutzerkennung, unter welcher der Webserver entweder selber läuft oder seine CGI-Skript startet (das kann eine noch unterprivilegiertere Kennung sein als die des Webservers selbst).
Und Du hast natürlich kein Recht, auf ein Objekt dieser Kennung zuzugreifen, falls Dir das Skript dieses Recht nicht erteilt hat. Das Skript muß also auch für das angelegte Verzeichnis das Schreibrecht erteilen, denn wenn Du eine Datei umbenennst, dann veränderst Du ja nicht den Inhalt der Datei, sondern den Inhalt des übergeordneten Verzeichnisses.

DirectoryListe statt der Zahl "65534" eine Teil aus meiner Pfadangabe stehen.

Es gibt gewisse Traditionen in UNIX. Eine davon ist es, die Benutzerkennung "nobody" auf den Wert "-2" zu setzen und dort "gefährliche" Prozesse aller Art laufen zu lassen. Und was könnte "65534" folglich bedeuten? 65536 minus 2, wäre mein Vorschlag.

Außerdem sollte doch bei chmod 777 rwxrwxrwx stehen?

Tut es wahrscheinlich auch, aber nur bei Deiner Datei, nicht beim übergeordneten Verzeichnis. Was für Deinen Zweck bisher nicht ausreicht.

[Michael N.]

Hallo Joerg, Michael, und die anderen,

Die DirectoryList zeigt in der Tat Merwürdiges:
drwxr-xr-x   2 65534    65534        1024 Jul 21 14:22 karl
wobei karl das neue Verzeichnis ist  :-)
Siehste wohl, mit guten Diagnosedaten kommen wir weiter.

Stimmt!!

"Dein" CGI-Skript wird nun mal nicht von *Dir* ausgeführt, sondern vom Webserver. Wenn es also ein Verzeichnis anlegt, dann gehört dieses Verzeichnis derjenigen Benutzerkennung, unter welcher der Webserver entweder selber läuft oder seine CGI-Skript startet (das kann eine noch unterprivilegiertere Kennung sein als die des Webservers selbst).

Und wenn dann noch das "permissions" beim Erstellen des Directories nicht so zieht, wie es hier bei dem Kommando steht, dann ist ja alles klar. Ich hab dieses Zitat bewusst nochmal aus dem Threadbeginn zurueckgeholt.
Statt

...>$permissions = 0777;
...>mkdir("$dirname",$permissions);

solltest Du mal versuchen:
$permissions = 0777;
mkdir("$dirname");

und dann erstmal ein:

chmod($permissions,"$dirname");

Und Du hast natürlich kein Recht, auf ein Objekt dieser Kennung zuzugreifen, falls Dir das Skript dieses Recht nicht erteilt hat. Das Skript muß also auch für das angelegte Verzeichnis das Schreibrecht erteilen, denn wenn Du eine Datei umbenennst, dann veränderst Du ja nicht den Inhalt der Datei, sondern den Inhalt des übergeordneten Verzeichnisses.

Wenn Du es natuerlich auf diesem Weg schaffst ein kollektives Schreibrecht auf das File zu erstellen, dann kannst Du und jeder andere User die Datei auch beschreiben.

Sicherer waere aber ein anderer Weg: Du laesst den Webserver wie gehabt alles erstellen, und laesst ihn dann, falls die Moeglichkeit besteht den ganzen Mist an Dich verkaufen mittels chown und setzt die Rechte auf -rwxr-xr-x, damit nicht jeder Cracker in Deinen Dateien rumarbeiten kann und Dir haessliche Ueberraschungen ala "Diese Seite wurde von xxx gecrasht!" bereiten kann.

Bis danndann

Michael N.

[Michael Schröpl]

Sicherer waere aber ein anderer Weg: Du laesst den Webserver wie gehabt alles erstellen, und laesst ihn dann, falls die Moeglichkeit besteht den ganzen Mist an Dich verkaufen mittels chown und setzt die Rechte auf -rwxr-xr-x, damit nicht jeder Cracker in Deinen Dateien rumarbeiten kann und Dir haessliche Ueberraschungen ala "Diese Seite wurde von xxx gecrasht!" bereiten kann.

Genau das.

Im Prinzip wärest Du am glücklichsten, wenn Deine CGI-Skripts unter Deiner Benutzerkennung laufen würden. Das ist aber nicht so einfach:
1. muß der Webmaster Dir vertrauen, daß Du nicht mehr Schaden anrichtest als "nobody" das könnte.
2. müßte der Webserver entweder Dein Skript explizit unter Deiner Kennung starten - bei Apache gibt es dazu ein Kapitel "suEXEC", das ich noch nicht gelesen habe - oder Dein Skript müßte dabei selbst "nachhelfen".

Letzteres würde voraussetzen, daß über CGI ein Programm auf eine Weise gestartet wird, welches das UNIX-s-Bit auswertet. Kurz gesagt: Durch ein viertes Bit (neben r, w und s) kann man die userid  bzw. die group des Prozesses, der beim Ausführen verwendet werden soll, aus den Attributen des Programms übernehmen. In Deinem Falle bist Du der owner von script.pl, und wenn Du mit "chmod u+s script.pl" das s-Bit setzt, würde das Skript unter  Deiner Kennung ausgeführt werden ... hm, wenn es denn selbst ausgeführt würde!

Wird es aber vermutlich nicht, wenn es ein Perl-Skript ist: Da müßte entweder das s-Bit für den Perl-Interpreter gesetzt werden und dieser in Deinen Besitz übergehen (macht der Webmaster bestimmt nicht - Du könntest höchstens lokal ein eigenes Perl installieren ...) oder der owner über die CGI-Ausführung hinweg transportiert werden (da hängt es aber vom UNIX-Dialekt ab, ob s-Bits in Skripten evaluiert werden - bei IBM-AIX hat sich das beispielsweise zwischen Version 3.1 und 3.2 geändert, und ich mußte anschließend ein C-Programm mit s-Bit dazwischenschalten, welches nichts anderes tat, als ein als Parameter übergebenes Skript unter dieser Berechtigung auszuführen ... seufz.

Egal: Frage Deinen Webmaster mal, ob er eine Möglichkeit sieht, daß Du CGI-Anwendungen unter Deiner Kennung laufen lassen kannst. Mehr als "nein" sagen kann er nicht.
Schlimmstenfalls mußt Du dann halt überall 777 als Berechtigung eintragen und alles sperrangelweit offen stehen lassen - nicht schön, aber funktioniert.

[Jörg Wittemeier]

Hallo Michael !

Du hast das Problem anscheinend voll durchschaut, im Gegensatz zu mir. So tief bin ich noch nicht in die Materie eingedrungen. Will doch nur ein Verzeichnis erstellen, in dem ich die Dateien umbennen oder löschen kann.<heul>

Hab eins höher mal die eMail von meinem admin gepostet, da ist die rede von unmask 000. Vielleicht gibt‚s ja doch noch eine einfache Lösung.

Gruß
Jörg

[Jörg Wittemeier]

Hallo Michael!

"Dein" CGI-Skript wird nun mal nicht von *Dir* ausgeführt, sondern vom Webserver. Wenn es also ein Verzeichnis anlegt, dann gehört dieses Verzeichnis derjenigen Benutzerkennung, unter welcher der Webserver entweder selber läuft oder seine CGI-Skript startet (das kann eine noch unterprivilegiertere Kennung sein als die des Webservers selbst).

Das scheint der Knackpunkt zu sein. Hab meinen Admin belästgt und folgende Mail erhalten.

<mail>....Da diese Verzeichnisse von einem CGI erstellt werden, und CGIs IMMER unter
der Userid des Webservers laufen (in diesem Falle nobody/nogroup, d.h.
65534/65534), werden so erstellte Verzeichnisse immer mit owner/group des
Webservers erstellt (mit der default umask von 022, d.h. Rechten von 755).

Um dies zu verhindern, muessen sie in Ihrem CGI die Rechte beim Erstellen
des Verzeichnisses anpassen. In Ihrem Fall muessen Sie die umask auf 000
stellen...</mail>

Leuchtet mir alles ein (so halbwegs), aber wie läuft das mit unmask auf 000 stellen????

...damit nicht jeder Cracker in Deinen Dateien rumarbeiten kann und Dir haessliche Ueberraschungen ala "Diese Seite wurde von xxx gecrasht!" bereiten kann.

klaro, werd ich beachten.

Gruß und schon mal Danke!
Jörg

[Michael Schröpl]

Das scheint der Knackpunkt zu sein. Hab meinen Admin belästgt und folgende Mail erhalten.

Du solltest Dich bei Deinem Admin ausdrücklich bedanken - er ist sowohl kooperativ als auch sachkundig! Das hat er sich verdient.

Um dies zu verhindern, muessen sie in Ihrem CGI die Rechte beim Erstellen
des Verzeichnisses anpassen. In Ihrem Fall muessen Sie die umask auf 000
stellen...</mail>
Leuchtet mir alles ein (so halbwegs), aber wie läuft das mit unmask auf 000 stellen????

"umask" (nicht "unmask") ist ein Kommando, mit welchem man eine Bit-Maske setzen kann, welche Zugriffsbits beim *Einrichten* eines Objekts (Verzeichnis bzw. Datei) *nicht* gesetzt werden sollen. Irgend ein Default muß dafür ja gelten, und das ist eben der, welcher durch umask (sinnvollerweise beim login im ".profile") gesetzt wird. "umask 022" ist ein verbreiteter Wwert, der bewirkt, daß Deine Objekte mit "755" (Verzeichnisse, dort ist das x-Bit allein schon zum Reinsehen notwendig) bzw. "644" (Dateien, dort ist das x-Bit nur zum Ausführen notwendig) gesetzt werden. "umask 000" würde also neue Verzeichnisse mit 777, neue Dateien mit 666 entstehen lassen.

Ich habe gerade folgendes auf meiner UNIX-Kiste (via Telnet) eingegeben:
   umask 022
   touch x             # leere Datei anlegen
   umask 000
   touch y             # leere Datei anlegen
   ls -l x y

und bekomme dabei folgende Ausgabe:
   -rw-r--r--   1 intranet adm            0 Jul 21 16:37 x
   -rw-rw-rw-   1 intranet adm            0 Jul 21 16:38 y

Die bereits beschriebene Möglichkeit, nachträglich "chmod 777" auf Dein Verzeichnis anzuwenden, würde Dein Problem aber ebenfalls lösen (und ist später leichter verständlich - bedenke, daß umask *alle* neu angelegten Objekte Deines CGI-Programms betrifft!).

Mit "CGI" hat das alles übrigens wenig zu tun - vielleicht sollten wir mal ein Topic "(UNIX)" einrichten ... (huch, schon wieder so ein Verbesserungsvorschlag, igitt ...)

[Jörg Wittemeier]

Hi !

Du solltest Dich bei Deinem Admin ausdrücklich bedanken - er ist sowohl kooperativ als auch sachkundig! Das hat er sich verdient.

Und Ihr auch :-))

Aber mit meinem Admin hab ich Super-Glück gehabt!
Ist der Beste. Wenn ich hier so manchmal die Probs höre...

"umask" (nicht "unmask") sorry, Laie :-)

Die bereits beschriebene Möglichkeit, nachträglich "chmod 777" auf Dein Verzeichnis anzuwenden, würde Dein Problem aber ebenfalls lösen (und ist später leichter verständlich - bedenke, daß umask *alle* neu angelegten Objekte Deines CGI-Programms betrifft!).

Konnte ich mir erst nicht vorstellen, hab‚s einfach probiert und es funzt!!!!!!!!!!!!!!
Nur wird kein Verzeichnis ohne chmod angelegt. Also:

$permissions = 0777;
mkdir("$dirname",$permissions);  <-- nicht ohne $permissions
chmod($permissions,"$dirname");

und schon läßt sich alles löschen.

Dir und den anderen vielen Dank für die ausführlichen Erklärungen. Bin wieder ein wenig schlauer geworden.

Jörg

[Michael Schröpl]

$permissions = 0777;
mkdir("$dirname",$permissions);  <-- nicht ohne $permissions
chmod($permissions,"$dirname");
und schon läßt sich alles löschen.

... und wenn das so fein funktioniert, kannst Du am Ende des Skripts mit

$permissions = 0555;
   chmod($permissions,"$dirname");

die Verzeichnisrechte wieder auf "nur lesen" zurücksetzen, dann pfuscht außer Deinem Skript niemand in diesem Verzeichnis herum.

Das Skript - und jedes andere, das diese Daten schreibend verarbeiten will - muß halt beim nächsten Mal erst wieder den Schlüssel im Schloß herumdrehen.
(Theoretisch kann dabei ein Synchronisationsproblem auftreten, wenn zwei CGI-Benutzer gleichzeitig in Deinen Daten herumlaufen und der eine den anderen aussperrt ... aber in diesem Falle mußt Du wahrscheinlich sowieso irgendwas synchronisieren, damit Deine Daten nicht durch parallele Schreibzugriffe ruiniert werden.)

[Andrea]

Hi Michael,

Andrea, prinzipiell hast Du damit recht, aber ein Modus 777 (-rwxrwxrwx-) erlaubt ja auf jeden Fall jedwedem das Schreibrecht und somit muesste Joerg auch die Datei beschreiben, ueberschreiben und loeschen duerfen, egal ob sie unter seiner ID oder einer anderen ID erstellt wurde.

Ooops, da hab' ich net recht hingeguckt.

Ich selbst hatte mal ein aehnlich geartetes Problem unter einer UNIX-Umgebung, ich durfte kein "chown" an einen User derselben Gruppe auf Files machen, die mir gehoerten. Die Syntax meines Befehls war 100% korrekt, ich war Directory-Owner und File-Owner. Am Schluss stellte sich heraus: aus Sicherheitsgruenden war die Nutzung von "chown" für User nicht gestattet, chown durfte nur der Admin machen und der hat das dann ohne Probleme gemacht (mittels meines Befehls, den ich ihm gemailt hatte). Dann erst hat er recherchiert und als Ergebnis kam das oben gesagte raus.

Interessant. Ich hatte keine Ahnung, dass die Rechte eines Users derart beschnitten werden duerfen.

Gruss, Andrea