apache2 ftp - permissions problem

[rudi_m]

Hallo,
Ich habe einen (virtuellen) web server mit DocumentRoot
/srv/www/htdocs/xyz
weches user:www gehoert und
die Rechte 775 hat.

Der user ist auch Mitglied der gruppe www (obwohl IMO hier nicht von belang)
und besitzt ftp Zugriff auf das DocumentRoot - kann also sein Zeugs da hochladen und der apache2 serviert schoen.

Nun habe ich folgendes Problem.
Manche php scripte legen files und Verzeichnisse im DocumentRoot an, die dann natuerlich wwwrun (apache2-user) gehoeren.
Im Falle von nicht_leeren Verzeichnisse koennen diese vom user nicht mehr via ftp geloescht werden (trotz 775 auf dem DocumentRoot)

Ich denke das muss ein standard Problem sein, welches sich sicher mit ACLs loesen laesst - aber gehts nicht auch ohne?

Sowas wie umask in php.ini oder httpd.conf?

Eventuell wuerde auch eine Art "chown" (zu wwwrun) in der ftp-server config helfen aber geht mit meinem vsftpd via xinetd sicher nicht

Ein SUID Bit fuer Verzeichnisse wuerde mein Problem auch loesen aber das funktioniert bei mir nicht (obwohl das auf andern Unixes zu klappen scheint!? - kann man das irgendwie aktivieren)

Vielen Dank fuer Hinweise,
cu,
Rudi

[netzmeister]

Hallo,

baue den Server /home/*user*/www basiert auf.
Dann stimmen die Berechtigungen.

Alles Andere macht in der Regel keinen Sinn.

Viele Grüße

Eicke

[rudi_m]

baue den Server /home/*user*/www basiert auf.
Dann stimmen die Berechtigungen.

Alles Andere macht in der Regel keinen Sinn.

ja, im Prinzip ist das das ja so
/srv/www/htdocs/*user*/

Kann man denn den apache so einstellen dass er diese Verzeichnisse mittels child prozessen, die dem jeweiligen user gehoeren servieren kann?

Selbst die userdirs (public_html) werden defaultmaessig von wwwrun bereitgestellt - also kann sich damit jeder user Dateien anlegen, die er nur wieder per php script wegbekommt! Warum dieses Verhalten die Standardeinstellung ist will mir nicht einleuchten - welcher Admin moechte staendig von den usern genervt werden: "ich kann xyz nicht loeschen nachdem ich mir Mambo installiert habe"

[netzmeister]

Das von Dir derzeit verwendete Prinzip macht bei shared Hosting
Servern überhapt keinen Sinn.

Mach es so wie ich es sage.

Viele Grüße

Eicke

[rudi_m]

Das von Dir derzeit verwendete Prinzip macht bei shared Hosting
Servern überhapt keinen Sinn.

Mach es so wie ich es sage.

err, das verstehe ich nicht ganz.
kannst Du mir bitte etwas naeher erlaeutern was du damit genau meinst?:

"baue den Server /home/*user*/www basiert auf.
Dann stimmen die Berechtigungen."

[Roger Wilco]

Kann man denn den apache so einstellen dass er diese Verzeichnisse mittels child prozessen, die dem jeweiligen user gehoeren servieren kann?

Die MPMs peruser, metux und perleader existieren, befinden sich aber entweder noch massiv in der Entwicklung oder wurden bereits aufgegeben.
Wenn dich stört, dass deine Skripte mit den Rechten des Webservers laufen, gibt es immer noch SuExec oder SuPHP. Du kannst natürlich auch für jeden Benutzer eine eigene Apache-Instanz laufen lassen und per Reverse Proxy die Anfragen richtig verteilen.

Warum dieses Verhalten die Standardeinstellung ist will mir nicht einleuchten

man UNIX permissions

[rudi_m]

Die MPMs peruser, metux und perleader existieren, befinden sich aber entweder noch massiv in der Entwicklung oder wurden bereits aufgegeben.
Wenn dich stört, dass deine Skripte mit den Rechten des Webservers laufen, gibt es immer noch SuExec oder SuPHP.

Danke das schau ich mir mal an!
Weiss zufaellig jemand welchen Weg z.B confixx geht? Da muss das Problem doch auch geloest sein. (Ich selbst besitze das nicht)

Du kannst natürlich auch für jeden Benutzer eine eigene Apache-Instanz laufen lassen und per Reverse Proxy die Anfragen richtig verteilen.

lol - Daran hab ich auch schon gedacht - eventuell per xinetd. (so wie es bei vsftpd laeuft)
Aber der apache2 kann seine Last wohl besser selbst verteilen.

man UNIX permissions

jaja - mir kommt es nur sehr eigenartig vor das sich jeder user auf jedem Linux mit default-apache2 sein eigenes userdir mit nicht loeschbaren Files zukleistern kann. D sollte man sicher nicht an den Unix permission system rummäkeln sondern eben an der default config des apache!
So wie es standard maessig ist muss man gar root sein nur um die DocumentRoots zu bearbeiten - das will doch niemand!

@Netzmeister
Den fundamentalen Unterschied zwischen
/home/*user*/www basiert
und
/srv/www/htdocs/*virtualhost*
verstehe ich immer noch nicht...

[Roger Wilco]

Weiss zufaellig jemand welchen Weg z.B confixx geht?

Standardsetup ist wohl Apache mit mod_php.

Da muss das Problem doch auch geloest sein.

Ist es nicht.

D sollte man sicher nicht an den Unix permission system rummäkeln sondern eben an der default config des apache!

Und nochmal: man UNIX permissions
Wie soll das denn funktionieren, ohne dass entweder für jeden Benutzer ein eigener Prozess/eine eigene Instanz läuft oder ein SUID/SGID Binary vorhanden ist, das als Wrapper für Skripte fungiert?

[rudi_m]

Ist es nicht.

Wie machen das denn die Professionellen Web-Hoster die confixx verwenden?

Wie soll das denn funktionieren, ohne dass entweder für jeden Benutzer ein eigener Prozess/eine eigene Instanz läuft oder ein SUID/SGID Binary vorhanden ist, das als Wrapper für Skripte fungiert?

Wo ist das problem? IMO zumindest fuer die userdirs wuerde so ein wrapper defaultmassig Sinn machen - obwohl SUID natuerlich ein Sicherheits risiko fuer den user.
Aber warum nicht einfach IMMER Schreibrechte fuer die Gruppe beim Anlegen von neuen fliles? Zusammen mit SGID-bit fuers userdir - und das wars.
Das waere mir am liebsten - umask xyz in der php.ini oder direkt in der httpd.conf - genau so wie es beim ftp server geht.

[Roger Wilco]

Wie machen das denn die Professionellen Web-Hoster die confixx verwenden?

Sorry, aber das ist IMHO ein Oxymoron.

Aber warum nicht einfach IMMER Schreibrechte fuer die Gruppe beim Anlegen von neuen fliles?

Weil Benutzer sich dann gegenseitig die Dateien zerschießen dürfen. Gut, wenn alle Dateien dem gleichen Benutzer gehören, ist das ebenfalls möglich.