nicht angemeldet
(Linux) (Rechteverwaltung) Webserver-Rechte
Hi,
ich habe eine blöde Frage zur Rechtevergabe unter Linux:
Ich habe einen Server mit mehreren Benutzern, die jeweils PHP-Skripte erzeugen können. Der Webserver hat seinen eigenen Usern und logischerweise Zugriff auf die PHP-Skripte aller anderen User. Wie verhindere ich jetzt aber, dass ein User ein PHP-Skript schreibt, dass Zugriff auf die Dateien der anderen User nimmt, wo doch dessen PHP-Skript nicht mit den Rechten des Benutzers, der es erstellt hat, sondern des Webservers läuft?
Schöne Grüße
Julian
-
Hallo Julian,
die Frage ist überhaupt nicht blöd, ich finde sie sogar ziemlich weitsichtig.
Ich nehme mal an jeder deiner User hat ein eigenes document root wo seine PHP Skripte liegen, z.B. die eines eigenen virtuellen Servers. Ab diesem document root abwärts sollte der owner für alle Dateien und Verzeichnisse der jeweilige User selbst sein und die Gruppenrechte auch so gesetzt sei, dass der Webserver selbst nicht schreiben darf. Damit hast du auch schon was du wollstest, denn ein PHP Skript eines Users, das unter den Rechten des Webservers ausgeführt wird, kann nicht auf die Daten eines anderen Users schreiben.
Es bleibe allerdeings evtl. kleine Logfiles oder Datafiles, die die PHP Skripte selbst beschreiben dürfen sollen. Denn dann muss ja der Webserver die berechtigung haben mittels PHP Skript auf so eine Datei zu schreiben und somit können es auch gleichzeitig alle PHP Skripte aller User. Da würde ich jetzt mal nachschauen ob man jeden virtuellen Server mit eigenen Zugriffsrechten bestücken kann.
Cruz
Hi,
ich habe eine blöde Frage zur Rechtevergabe unter Linux:
Ich habe einen Server mit mehreren Benutzern, die jeweils PHP-Skripte erzeugen können. Der Webserver hat seinen eigenen Usern und logischerweise Zugriff auf die PHP-Skripte aller anderen User. Wie verhindere ich jetzt aber, dass ein User ein PHP-Skript schreibt, dass Zugriff auf die Dateien der anderen User nimmt, wo doch dessen PHP-Skript nicht mit den Rechten des Benutzers, der es erstellt hat, sondern des Webservers läuft?Schöne Grüße
Julian-
Hello,
Ich nehme mal an jeder deiner User hat ein eigenes document root wo seine PHP Skripte liegen, z.B. die eines eigenen virtuellen Servers. Ab diesem document root abwärts sollte der owner für alle Dateien und Verzeichnisse der jeweilige User selbst sein und die Gruppenrechte auch so gesetzt sei, dass der Webserver selbst nicht schreiben darf. Damit hast du auch schon was du wollstest, denn ein PHP Skript eines Users, das unter den Rechten des Webservers ausgeführt wird, kann nicht auf die Daten eines anderen Users schreiben.
Das ist mir zu schwabbelig :-)
Man unterscheidet mindestens erstmal zwischen den Versionen
- Modul
- CGI
Dann gibt es noch Zusatztools wie
- SUPHP
- RootShell
...
Und schließlich muss man noch überlegen, welche Möglichkeiten das OS überhaupt bietet.
Harzliche Grüße vom Berg
http://www.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
Hi Cruz,
Ich nehme mal an jeder deiner User hat ein eigenes document root wo seine PHP Skripte liegen, z.B. die eines eigenen virtuellen Servers.
Ich glaube, du meinst eher virtuelle Hosts.
Ab diesem document root abwärts sollte der owner für alle Dateien und Verzeichnisse der jeweilige User selbst sein und die Gruppenrechte auch so gesetzt sei, dass der Webserver selbst nicht schreiben darf.
Das dürfte einen File-Upload unmöglich machen...
Damit hast du auch schon was du wollstest, denn ein PHP Skript eines Users, das unter den Rechten des Webservers ausgeführt wird, kann nicht auf die Daten eines anderen Users schreiben.
Und dadurch lassen sich keine Flatfiles nutzen, kein SQLite, du kannst keine Dateien verwalten, du kannst keine Software wie z.B. eine Bildergalerie laufen lassen... usw.
Da würde ich jetzt mal nachschauen ob man jeden virtuellen Server mit eigenen Zugriffsrechten bestücken kann.
Du meinst immer noch virtuelle Hosts - virtuelle Server sind etwas ganz anderes. Und für die kannst du keine speziellen Zugriffsrechte setzen. Du kannst allerdings (wie bereits von Tom erwähnt) ein Zusatzmodul wie suexec (wenn PHP als CGI läuft) oder suphp (wenn PHP als Modul läuft) einsetzen, welches PHP unter einem anderen User als apache laufen lässt und das kannst du dann für jeden virtuelle Host einzeln festlegen.
MfG, Dennis.
-
Hallo,
Ab diesem document root abwärts sollte der owner für alle Dateien und Verzeichnisse der jeweilige User selbst sein und die Gruppenrechte auch so gesetzt sei, dass der Webserver selbst nicht schreiben darf.
Das dürfte einen File-Upload unmöglich machen...
die Vermutung ist für CGI jedenfalls unbegründet. Der Upload und das Anlegen von temporären Datein wird nicht vom Webserver verwaltet, sondern von PHP.
Damit hast du auch schon was du wollstest, denn ein PHP Skript eines Users, das unter den Rechten des Webservers ausgeführt wird, kann nicht auf die Daten eines anderen Users schreiben.
Und dadurch lassen sich keine Flatfiles nutzen, kein SQLite, du kannst keine Dateien verwalten, du kannst keine Software wie z.B. eine Bildergalerie laufen lassen... usw.
Wieso soll man keine Datein/SQLite nutzen können? Dieses wäre nur für mod_php ein Problem. Als (Fast)CGI ist das immer noch möglich.
Gruß aus Berlin!
eddi-
Hi eddi,
Das dürfte einen File-Upload unmöglich machen...
die Vermutung ist für CGI jedenfalls unbegründet.
Jein - nur bei der Verwendung von PHP als CGI in Verbindung mit suExec - ohne suExec werden ja auch die CGI Programme (und so mit auch PHP) als User apache ausgeführt, und apache soll ja wie oben von Cruz genannt keine Schreibrechte erhalten (was ja an sich sinnvoll ist, aber auf suExec hinausläuft).
Wieso soll man keine Datein/SQLite nutzen können? Dieses wäre nur für mod_php ein Problem. Als (Fast)CGI ist das immer noch möglich.
SQLite sind ja im Prinzip nichts anderes als Dateien - und da bisher von dem Einsatz von suExec oder suPHP keine Rede war, apache aber keinen Schreibzugriff erhalten sollte, ist das Schreiben (und damit das „Nutzen“) von Dateien ausgeschlossen.
Deine Aussage stimmt aber so nicht - es ist nicht generell für mod_php ein Problem, wenn du mod_php mit suPHP einsetzt, geht es wieder Problemlos, ohne das geht es (bei fehlenden Schreibrechten für apache) nicht. Genauso ist es mit CGI/FastCGI - ohne suExec geht es auch hier nicht, mit suExec geht es.
MfG, Dennis.
-
Moin Dennis,
... und da bisher von dem Einsatz von suExec oder suPHP keine Rede war, ...
achso - dann war ich nur zu vorschnell. (Von suPHP halte ich im Übrigen gar nichts.)
Gruß aus Berlin!
eddi-
Hi eddi,
Von suPHP halte ich im Übrigen gar nichts.
Warum das nicht wenn ich fragen darf? Ich habe es bis jetzt noch nie eingesetzt, sondern stattdessen immer suExec mit einem Starterscript für PHP - ich vermute das entspricht der von dir bevorzugten Methode…
MfG, Dennis.
-
Hallo Dennis,
Warum das nicht wenn ich fragen darf? Ich habe es bis jetzt noch nie eingesetzt, sondern stattdessen immer suExec mit einem Starterscript für PHP - ich vermute das entspricht der von dir bevorzugten Methode…
produktiv setze ich auf CGI und ggf. auf FastCGI. Eine Maschine wird über mod_php bedient, wobei hier die Beschränkung ausschließlich über die PHPeigenen Konfigurationen bewerkstelligt wird und sich dies bewehrt. Es ist noch im Test, aber wenn sich nicht bald irgendein Problem einstellt, werd ich generell auf mod_php setzen. Das ist deshalb auch kein Problem, weil kein FTP-Server zum Einsatz kommt, sondern WebDAV genutzt wird - somit alles ein User ist.
Meine ablehnende Haltung suPHP gegenüber gründet darauf, daß dabei ein Netzwerkdienst mit root-Rechten am lauschen ist.
Gruß aus Berlin!
eddi
-
-
-
Hallo Dennis,
wenn du mod_php mit suPHP einsetzt,
Ähm nein, suPHP ist zwar ein Apache-Modul, es ruft PHP als CGI auf. Deswegen entfällt der Geschwindigkeitsvorteil von mod_php - deswegen kann man in meinen Augen sowieso besser suExec verwenden, da suExec intensiv getestet und der Code sorgfältig inspiziert wurde über die Jahre hinweg. Einziger Vorteil von suPHP: die PHP_AUTH_*-Variablen für HTTP-Authentifizierung werden im Gegensatz zu normalem CGI gesetzt.
Viele Grüße,
Christian-
Hi Christian,
Ähm nein, suPHP ist zwar ein Apache-Modul, es ruft PHP als CGI auf.
Achso - ok, das war mir so nicht bewusst, wie gesagt - ich habe suPHP noch nie eingesetzt, soweit ich weiß verwendet CK es bei Occuris (oder hat es mal verwendet).
MfG, Dennis.
-
-
-
-
-
-
Hello,
Wie verhindere ich jetzt aber, dass ein User ein PHP-Skript schreibt, dass Zugriff auf die Dateien der anderen User nimmt, wo doch dessen PHP-Skript nicht mit den Rechten des Benutzers, der es erstellt hat, sondern des Webservers läuft?
Wenn der Webserver mit PHP als Modul läuft, was ich Deinen bisherigen Ausführungen nach vermute, im Wesentlichen durch das Setzen von
open_basedir
Dann regelt zwar PHP den Zugriff, also die Applikation und nicht der Server, ist aber immer noch besser, als wenn gar keiner etwas regelt.
Als nächstes musst Du überlegen, durch welche Funktionen die Beschränlung noch unterlaufen werden könnte. Da kommen dann als erstes die
exec-Funktionen
in Betracht. Die kann man recht brutal mittels
safe_mode = ON
ausschalten, was aber zu weiteren unnötigen Problemen führen wird.
Experiementier mal ein wenig und lies Dich über den Weg "open_basedir" ins Manual ein.
Wenn es kneift, frag.Harzliche Grüße vom Berg
http://www.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
Hi,
Wie verhindere ich jetzt aber, dass ein User ein PHP-Skript schreibt, dass Zugriff auf die Dateien der anderen User nimmt, wo doch dessen PHP-Skript nicht mit den Rechten des Benutzers, der es erstellt hat, sondern des Webservers läuft?
Wenn der Webserver mit PHP als Modul läuft, was ich Deinen bisherigen Ausführungen nach vermute, im Wesentlichen durch das Setzen von
open_basedir
Dann regelt zwar PHP den Zugriff, also die Applikation und nicht der Server, ist aber immer noch besser, als wenn gar keiner etwas regelt.
angenommen ich würde meine Problembeschreibung auch auf beliebige Typen von CGI-Programmen ausweiten, ist eine Lösung auf Basis von PHP aber nicht akzeptabel - d. h. safemode ist nur geeignet, wenn es ausschließlich um PHP geht (was momentan der Fall ist). Aber wenn ich langfristig auch einigen Usern die Ausführung von CGI-Skripten erlauben möchte, habe ich das gleiche Problem wieder. Gibt es eine allgemein gültige Lösung, ohne dass ich für jeden User einen eigenen Webserver einrichten muss?
Schöne Grüße
Julian-
Hi,
wenn ich jetzt vorläufig in den VirtualHost-Einstellungen jeden Users open_basedir auf sein Home-Verzeichnis setzen würde, müsste ich aber auch noch abschalten, dass der User z. B. per system() Befehle mit den Rechten des Webservers ausführen kann. Ich möchte meinen Usern aber die Möglichkeit geben, Linux-Programme wie z. B. "convert" etc. zu nutzen. Ich habe gerade gelesen, es gibt mit Apache 2 die Möglichkeit, für einen VirtualHost zu bestimmen, unter welchem User Programme ausgeführt werden. Hat jemand eine Quelle, wo ich nähere Infos finde?
Schöne Grüße
Julian-
Hi,
wenn ich jetzt vorläufig in den VirtualHost-Einstellungen jeden Users open_basedir auf sein Home-Verzeichnis setzen würde, müsste ich aber auch noch abschalten, dass der User z. B. per system() Befehle mit den Rechten des Webservers ausführen kann. Ich möchte meinen Usern aber die Möglichkeit geben, Linux-Programme wie z. B. "convert" etc. zu nutzen. Ich habe gerade gelesen, es gibt mit Apache 2 die Möglichkeit, für einen VirtualHost zu bestimmen, unter welchem User Programme ausgeführt werden. Hat jemand eine Quelle, wo ich nähere Infos finde?
suPHP löst das Problem zumindest schonmal für PHP.
Schöne Grüße
Julian-
Hello,
suPHP löst das Problem zumindest schonmal für PHP.
Das funktioniert aber nur bedingt.
Harzliche Grüße vom Berg
http://www.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
Hi,
suPHP löst das Problem zumindest schonmal für PHP.
Das funktioniert aber nur bedingt.
kannst du noch etwas ausführen, was genau nicht funktioniert? Momentan wirkt es auf mich so, als wäre es für PHP eine gute Lösung.
Schöne Grüße
Julian-
Hello,
suPHP löst das Problem zumindest schonmal für PHP.
Das funktioniert aber nur bedingt.
kannst du noch etwas ausführen, was genau nicht funktioniert? Momentan wirkt es auf mich so, als wäre es für PHP eine gute Lösung.
Jein. Ich bin da nicht up to date.
Die Beschreibung, die unter Deinem Link zu finden ist, sieht inzwischen wirklich ganz hoffnungsfroh aus. Es ist aber immer noch meine 1.x-Version, also immer noch experimentell. Deshalb würde ich selber nicht wagen, die Schicht-Software im (harten) produktiven Umfeld einzusetzen.Jedenfalls sollte man noch ein wenig querlesen, in welchem genauen Umfeld (Versions-Kombinationen) sie sich bereits bewährt hat.
Mit suexec sieht es da wohl schon etwas besser aus.
Harzliche Grüße vom Berg
http://www.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
Hello,
Es ist aber immer noch keine 1.x-Version,
Ich plädiere für Korrekturmöglichkeit, bis Antworten vorliegen!!
Harzliche Grüße vom Berg
http://www.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
-
-
-
Hi Julian,
suPHP löst das Problem zumindest schonmal für PHP.
Nutze stattdessen lieber suExec - das wird dann für alle CGI-Programme verwendet. Wenn du dann PHP als CGI-Version einsetzt kannst du suExec auf für PHP verwenden, du brauchst dann ein kleines Shell-Script als "PHP-Starter".
Ein gutes HowTo zu dem Thema ist dieses hier - du musst es ja nicht gleich auch noch mit FastCGI machen, du kannst es auch mit normalem CGI machen, die Vorgangsweise ist equivalent.
MfG, Dennis.
-
Hi,
suPHP löst das Problem zumindest schonmal für PHP.
Nutze stattdessen lieber suExec - das wird dann für alle CGI-Programme verwendet. Wenn du dann PHP als CGI-Version einsetzt kannst du suExec auf für PHP verwenden, du brauchst dann ein kleines Shell-Script als "PHP-Starter".
Ein gutes HowTo zu dem Thema ist dieses hier - du musst es ja nicht gleich auch noch mit FastCGI machen, du kannst es auch mit normalem CGI machen, die Vorgangsweise ist equivalent.
Danke!
Schöne Grüße
Julian-
Hi Julian,
Ein gutes HowTo zu dem Thema ist dieses hier - du musst es ja nicht gleich auch noch mit FastCGI machen, du kannst es auch mit normalem CGI machen, die Vorgangsweise ist equivalent.
Danke!
Bitte ;-)
Dieses HowTo ist zwar auf Debian zugeschnitten, aber natürlich auf andere Linux-Systeme übertragbar - die Software Installation mag sich dann unterscheiden, die Konfiguration sollte aber nahezu identisch sein.
MfG, Dennis.
-
Hi,
Ein gutes HowTo zu dem Thema ist dieses hier - du musst es ja nicht gleich auch noch mit FastCGI machen, du kannst es auch mit normalem CGI machen, die Vorgangsweise ist equivalent.
Danke!
Bitte ;-)
Dieses HowTo ist zwar auf Debian zugeschnitten, aber natürlich auf andere Linux-Systeme übertragbar - die Software Installation mag sich dann unterscheiden, die Konfiguration sollte aber nahezu identisch sein.
ich verwende sowieso Debian Sarge. Hast du für die Frage in https://forum.selfhtml.org/?t=125469&m=808925 noch einen Tipp?
Schöne Grüße
Julian
-
-
-
-
-
Hello,
wenn ich jetzt vorläufig in den VirtualHost-Einstellungen jeden Users open_basedir auf sein Home-Verzeichnis setzen würde, müsste ich aber auch noch abschalten, dass der User z. B. per system() Befehle mit den Rechten des Webservers ausführen kann. Ich möchte meinen Usern aber die Möglichkeit geben, Linux-Programme wie z. B. "convert" etc. zu nutzen. Ich habe gerade gelesen, es gibt mit Apache 2 die Möglichkeit, für einen VirtualHost zu bestimmen, unter welchem User Programme ausgeführt werden. Hat jemand eine Quelle, wo ich nähere Infos finde?
*ups*
dann wird es kompliziert.
Es gibt dann nämlich das "so sollte es funktionieren" und das "so funktioniert es bei Version xy" und das "so könnte es versehentlich auch noch gehn"
Eddi (Berlin) hat sich damit auch schon ziemlich intensiv auseinandergesetzt und ich hoffe, dass er mitliest, damit ich Dir hier nichts falsches sage... :-)
Strategie 1:
- open_basedir
- eigenes Upload-Verzeichnis
- eigenes Session-Verzeichnis
- Safe-Mode (User) anschalten
- safe_mode_exec_dir ist gesetze aber leer
Wenn man Systemprogamme zulässt, muss auf jeden Fall geklärt sein, woher diese ihre Daten beziehen dürfen.
Ich befürchte, dass hier noch eine gefährliche Lücke in PHP steckt.
Harzliche Grüße vom Berg
http://www.annerschbarrich.deTom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-
Hi Tom,
dann wird es kompliziert.
Nicht unbedingt - ich würde dazu raten, auf den SafeMode zu verzichten, zumal die Pläne für PHP6 vorsehen, den SafeMode _komplett_ zu entfernen.
Folgende Kombinationen sind möglich:
- Apache mit mod_suphp und mod_suexec, PHP als Modulversion wird über suPHP als der
User ausgeführt und CGI Programme über suExec - Apache mit mod_suexec, PHP als CGI-Version läuft mit einem kleinen Starter-Shell-Script
über suExec, CGI Programme ebenso
Ich setze letzere Methode ein (ein Modul weniger zum warten) und kann nur positives davon berrichten.
Strategie 1:
- open_basedir
Das zu setzen kann eigentlich nie schaden.
- eigenes Upload-Verzeichnis
- eigenes Session-Verzeichnis
Brauchst du bei suExec/suPHP nicht mehr, wenn du Umask so gesetzt hast, dass die Welt nicht lesen darf, dann gehören die Dateien nämlich dein einzelnen Usern und deren Gruppen und sind somit für andere nicht mehr lesbar.
- Safe-Mode (User) anschalten
- safe_mode_exec_dir ist gesetze aber leer
Pfui, macht meiner Meinung nach nur Probleme, mit dem SafeMode habe ich nur negative Erfahrungen gemacht.
Wenn man Systemprogamme zulässt, muss auf jeden Fall geklärt sein, woher diese ihre Daten beziehen dürfen.
Durch suExec/suPHP wird das über die normale Rechtevergabe eines Linuxsystems geklärt - wenn dann User
whoamikeinen Zugriff auf XY hat, hat er eben keinen Zugriff.MfG, Dennis.
- Apache mit mod_suphp und mod_suexec, PHP als Modulversion wird über suPHP als der
-
-
-
-
Hi,
gibt es eine Möglichkeit, eine Apache-Direktive wie
<Directory /home/user>
php_admin_value open_basedir /home/user
</Directory>
auf alle Verzeichnisse in /home/ anzuwenden, und dabei immer das entsprechende Base-Directory zu setzen?Schöne Grüße
Julian-
Hi Julian,
gibt es eine Möglichkeit, eine Apache-Direktive wie
<Directory /home/user>
php_admin_value open_basedir /home/user
</Directory>
auf alle Verzeichnisse in /home/ anzuwenden, und dabei immer das entsprechende Base-Directory zu setzen?So etwas ist meines Wissens nach nicht möglich - du kannst zwar <Directory /home/*> schreiben, aber es gibt dann nicht so wie bei regulären Ausdrücken eine Möglichkeit über $1 auf den Wert für * zurück zu greifen - das ich nicht weiß wie es geht, heißt aber natürlich nicht, dass es auch tatsächlich nicht möglich ist ;-)
MfG, Dennis.
-
Hi,
gibt es eine Möglichkeit, eine Apache-Direktive wie
<Directory /home/user>
php_admin_value open_basedir /home/user
</Directory>
auf alle Verzeichnisse in /home/ anzuwenden, und dabei immer das entsprechende Base-Directory zu setzen?So etwas ist meines Wissens nach nicht möglich - du kannst zwar <Directory /home/*> schreiben, aber es gibt dann nicht so wie bei regulären Ausdrücken eine Möglichkeit über $1 auf den Wert für * zurück zu greifen - das ich nicht weiß wie es geht, heißt aber natürlich nicht, dass es auch tatsächlich nicht möglich ist ;-)
schade. Dann hab ich wohl etwas mehr Tipparbeit. Danke.
Schöne Grüße
Julian
-
-