Derzeit laufen auf einem Server die User als vhosts mit suexec. Allerdings würde ich besser asu Performancegründen auf mod_perl (2.0.3) umstellen.

ich habe jetzt bspw. folgendes:
Der Apache läuft als: apache:apache
Das Verzeichnis eines Users hat: max1234:psasrv
psasrv beinhaltet auch nochmals den User apache.
Die darin liegenden Dateien (durch den FTP-Upload): max1234:psacln

Das Skript hat die Rechte 755 mit max1234:pscln und läuft korrekt.
Will der Apache mit mod_perl nun auf Dateien des Users max1234 zugreifen, klappt das natürlich nicht, weil die Gruppenrechte der Dateien ja nicht stimmen.
Ansonsten kreiert der Apache bei mod_perl ja immer Dateien mit apache:apache.

Sehe ich das richtig, dass mod_perl und unterschiedliche User nicht so einfach möglich sind, die ihre eigenen Dateien gegeneinander abschotten können?

Quote

mod_perl 2.0 improves the situation, since it allows a pool of Perl interpreters to be dedicated to a single virtual host. It is possible to set the UIDs and GIDs of these interpreters to be those of the user for which the virtual host is configured, so users can operate within their own protected spaces and are unable to interfere with other users.

<http://www.modperlbook.org/html/C-1-Users-Sharing-...>

Das Klonen der PerlInterpreter in mod_perl ist nichts, oder?

Hallo Gwen,

nur um das nochmal richtig zu verstehen...

Du möchtest, dass apache:apache auf Dateien von max1234:psacln
zugreifen darf? Das Skript läuft als max1234:psacln, Dateien werden
also auch mit dieser Konstellation angelegt. Dann reicht ein:

usermod -G psacln apache

Der Pfad bis zur Datei muss natürlich auch lesbar für den Apache sein,
dass heißt:

/home/max1234/inbox/datei.html

Wenn die Rechte von max1234 beispielsweise so gesetzt sind, dass der
Apache da nicht lesen darf, dann schafft er es auch nicht, bis zu datei.html
zu gelangen.

Eine weitere Möglichkeit ist folgende:

mkdir /var/www/irgendwas/inbox
chown max1234:apache /var/www/irgendwas/inbox
chmod 750 /var/www/irgendwas/inbox
chmod g+s /var/www/irgendwas/inbox

Dateien können dort vom User max1234 angelegt werden
und erhalten automatisch die Gruppe apache.

Noch eine Möglichkeit wären erweiterte ACLs...

Leide kenne ich nicht genau dein Konstrukt, kann also nur im Dunkeln
Tipps geben, aber vielleicht reicht das ja auch schon.

Gruss,
bloonix

Arg, ich habe übersehen, dass das Verzeichnis nurlesbar für den Apache war. *blindflug*

Na ja, ein umask(117) in Perl-Skript setzt ja die richtigen Dateirechte.

Allerdings besteht ja immer noch das Problem, dass alle durch den Apache erzeugten Dateien aus allen mod_perl-Skripten lesbar sind, wenn der andere User das Verzeichnis weiß/errät.
Bei einem Webspace, der meist unter /var/www/ oder /srv/www liegt, ist das wohl einfach zu erraten.

mod_perl lässt sich ja nicht jailen.

Also ist mod_perl nicht für Server mit mehreren Domains/Nutzern, was die Sicherheit beim Zugriff auf andere Verzeichnisse anbelangt, unmöglich.

Oder verwendet hier niemand mod_perl auf einem vhost?

GwenDragon+2008-05-20 13:48:28--

Also ist mod_perl nicht für Server mit mehreren Domains/Nutzern, was die Sicherheit beim Zugriff auf andere Verzeichnisse anbelangt, unmöglich.

ich denke schon. wie ist das eigentlich bei mod_php? würde mich mal interessieren, weiss das jemand?

Ob bei mod_php auch andere Verzeichnisse gelesen werden können?

GwenDragon+2008-05-20 14:27:01--

Ob bei mod_php auch andere Verzeichnisse gelesen werden können?

naja, generell, ob bei mod_php alles unter demselben user läuft. dann können natürlich
auch untereinander verzeichnisse gelesen werden. und ob alles in denselben prozessen
läuft oder jeder seine eigenen prozesse bekommt.

Wenn safe_mode abgeschaltet ist, läuft alles als root!
Wenn open_basedir abgeschaltet ist, können von überall Dateien gelesen werden.

Anscheinen sind die PIDs unterschiedlich, was wohl auf getrennte Prozesse schließen lässt - aber nicht immer!

Wohin so ein netter system-Aufruf mit mod_php führt, kannst du unter http://bugs.php.net/bug.php?id=38915 lesen!

Im Grunde genommen ist es besser suexec oder suphp zu verwenden. Da läuft das Skript nur mit uid und gid des Users und kann dan nicht sonstwo herumwüten.