Hallo,
ich hab meinen apache weitestgehend wie im debianhowto beschrieben eingerichtet, außerdem setzte ich die Web- und FTP-User Konfigurations-HOWTO Userkonfiguration ein. Leider stellt sich ein Problem. Wenn ich scripte habe die Dateien selber erstellen, bekommen, die neuen Dateien immer die Rechte des apache. Das kommt dann suexec in die quere. Das heißt, dass ich die Dateien dann teilweise nicht verwenden kann über den apache.
Wie kann ich das ändern? Wäre das setzten des â??sâ?? bits eine empfehlenswerte Methode? Oder würde das nichts bringen?
Mit freundlichen Grüßen,
Bodo
suexec / uid - gid
Re: suexec / uid - gid
Moment mal... wenn die Skripte, die diese neuen Dateien erstellen über suEXEC aufgerufen werden, dann sollten diese neuen Dateien auch die Rechte des jeweiligen Nutzers erhalten. Du solltest also einfach darauf achten, dass man suEXEC bei dir nicht umgehen kann, dann sollten sich diese Probleme von alleine lösen...Wenn ich scripte habe die Dateien selber erstellen, bekommen, die neuen Dateien immer die Rechte des apache. Das kommt dann suexec in die quere.
Wenn du dir anschaust, wie suEXEC funktioniert, wirst du feststellen, dass dann darüber mit suid-bit gar nichts mehr geht.Wäre das setzten des â??sâ?? bits eine empfehlenswerte Methode?
Re: suexec / uid - gid
Wie mach ich das, dass man suexec nicht umgehen kann? Mir sind nur die folgenden Möglichkeiten bekannt suexec zu konfigurieren:
- User und Group im vHost angeben zum aktivieren von suexec
- Suexec in apache einkompilieren (bei debian deutet das DocRoot ja auf /var/www)
- Scripte im vHost DocRoot müssen User und Group entsprechen
Ich verstehe sowieso nicht, wie das denn überhaupt möglich ist das über scripte erstellte Dateien nicht den in der vHost Konfig angegebenen Benutzern entsprechen â?¦.. Aber ich hab jetzt schon 2 perl Aplikationen bei denen das nicht funzt â?¦. Leider sind die Erläuterungen zu suexec meist ziemlich dürftig â?¦
-edit:
Ha ich glaub ich weiß woran es liegen könnte:
als httpd_user habe ich www-data, aber meine vHosts haben alle als Gruppe ftpuser der apache hat www-data als user und group.
Könnte es sein das suexec da irgendwas verpeilt beim schreiben und den einkompilierten user verwendet oder so? Weil neue Dateien werden halt mit www-data.www-data geschrieben â?¦..
meine vHosts sehen etwa wie folgt aus:
- User und Group im vHost angeben zum aktivieren von suexec
- Suexec in apache einkompilieren (bei debian deutet das DocRoot ja auf /var/www)
- Scripte im vHost DocRoot müssen User und Group entsprechen
Ich verstehe sowieso nicht, wie das denn überhaupt möglich ist das über scripte erstellte Dateien nicht den in der vHost Konfig angegebenen Benutzern entsprechen â?¦.. Aber ich hab jetzt schon 2 perl Aplikationen bei denen das nicht funzt â?¦. Leider sind die Erläuterungen zu suexec meist ziemlich dürftig â?¦
-edit:
Ha ich glaub ich weiß woran es liegen könnte:
Code: Select all
/usr/lib/apache/suexec -V
-D DOC_ROOT="/var/www"
-D GID_MID=100
-D HTTPD_USER="www-data"
-D LOG_EXEC="/var/log/apache/suexec.log"
-D SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
-D UID_MID=100
-D USRDIR_SUFFIX="public_html"Könnte es sein das suexec da irgendwas verpeilt beim schreiben und den einkompilierten user verwendet oder so? Weil neue Dateien werden halt mit www-data.www-data geschrieben â?¦..
meine vHosts sehen etwa wie folgt aus:
Code: Select all
<VirtualHost xxx.xxx.xxx.xxx>
ServerName xxx.xxx.xxx.xxx
User default
Group ftpuser
DocumentRoot /var/www/default/domain/html
</VirtualHost>
Re: suexec / uid - gid
Hi,
schau mal in die log-Datei von suexec, bei debian /var/log/apache/suexec.log, da steht, welche der suexec-Sicherungsmaßnahmen fehlschlägt. Also ob es an Dateiberechtigungen, Pfaden oder was auch immer liegt.
schau mal in die log-Datei von suexec, bei debian /var/log/apache/suexec.log, da steht, welche der suexec-Sicherungsmaßnahmen fehlschlägt. Also ob es an Dateiberechtigungen, Pfaden oder was auch immer liegt.
Re: suexec / uid - gid
Hi, bei dem einen script scheints wirklich an den rechten zu liegen, bei dem anderen scheint es aber etwas anderes zu sein .... naja mal schauen...