suexec + mod_fcgid + php-cgi - Rechte-Problem? (FreeBSD)

[codepoet]

Moin zusammen!

Ich habe ein kleines Problem und brauche mal 'n Denkanstoß in die richtige Richtung ...

Folgende Situation:

- FreeBSD 7.2 PRERELEASE + Jails (funktioniert soweit alles stabil)
- Webserver-Jail mit ...
- Apache 2.2 (inkl. suexec + mod_fcgid)
- PHP5 (sowohl Modul, als auch CGI-Version vorhanden)

Die wichtigsten Konfigurationen:

betroffener vHost

Code: Select all

<VirtualHost *:80>
  #
  # Domain: example.org
  # Host:   temp
  #

  ServerName            temp.example.org

  ServerAdmin           support@example.org

  DirectoryIndex        index.html index.htm index.php index.php3 index.php4 index.php5

  CustomLog             /usr/local/www/virtual/temp.example.org/logs/access_log combined
  ErrorLog              /usr/local/www/virtual/temp.example.org/logs/error_log

  # - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  # SuexecUserGroup       example_user example_group

  # - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  # php_admin_flag      engine off

  FCGIWrapper           /usr/local/www/virtual/temp.example.org/php/wrapper .php

  DefaultInitEnv        PHPRC "/usr/local/www/virtual/temp.example.org/php"
  DefaultInitEnv        PHP_FCGI_CHILDREN "5"
  DefaultInitEnv        PHP_FCGI_MAX_REQUESTS "100"

  AddHandler            fcgid-script .php .php3 .php4 .php5 .phtml

  # - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  DocumentRoot          "/usr/local/www/virtual/temp.example.org/htdocs/"

  <Directory "/usr/local/www/virtual/temp.example.org/htdocs/">
    Options             Indexes FollowSymLinks ExecCGI
    AllowOverride       None

    Order               allow,deny
    Allow               from all
  </Directory>
</VirtualHost>

suexec

Code: Select all

[root@www1 virtual]# suexec -V
 -D AP_DOC_ROOT="/usr/local/www/virtual"
 -D AP_GID_MIN=10000
 -D AP_HTTPD_USER="www"
 -D AP_LOG_EXEC="/var/log/httpd-suexec.log"
 -D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
 -D AP_UID_MIN=10000
 -D AP_USERDIR_SUFFIX="public_html"

wrapper (PHP-Wrapper)

Code: Select all

root@www1 php]# cat wrapper 
#!/bin/sh

exec /usr/local/bin/php-cgi "$@"

Das ganze funktioniert in dieser Konfiguration auch genau so wie es soll. Das Problem entsteht erst, wenn ich die
"SuexecUserGroup"-Anweisung in der vHost-Konfiguration einkommentiere.

Ich erhalte dann im Log des betroffenen vHosts ...

Code: Select all

[Thu Apr 23 11:47:19 2009] [error] [client XXX.XXX.XXX.XXX] Premature end of script headers: index.php
[Thu Apr 23 11:56:23 2009] [warn] (53)Software caused connection abort: mod_fcgid: read data from fastcgi server error.

Ich vermute ein Rechte-Problem, da der FastCGI-Prozess, welcher die Anfrage bearbeiten soll ja den Benutzer wechselt,
was natürlich gewollt ist und dann nicht mehr auf den FastCGI-Socket zugreifen kann. - Genau weiß ich dies aber nicht.

Mir scheint der Ablauf in welchem ein solcher Request beantwortet wird nicht ganz klar zu sein ...

- Request kommt
- Apache erkennt eine Anfrage auf ein CGI-Skript (in diesem Fall PHP)
- FastCGI-Prozess wird gespawnt
- ...

Und genau jetzt frage ich mich, warum der FastCGI-Prozess die Rechte des Webservers ("www") hat (man sieht dies daran,
dass der Socket auch mit diesen Rechten erstellt wird) und nicht die des durch die entsprechende "suexec"-Anweisung
geforderten!?

Evtl. handelt es sich aber auch um gar kein Rechte-Problem, da ja auch keines im Log beklagt wird, dies sollte der Fall
sein (lt. fcgid-Source).

Hat jemand eine Idee?


Dank euch ... Stefan

[daemotron]

Wenn Du möchtest, dass FastCGI-Prozesse mit einem bestimmten User gespawnt werden, kommst Du nicht umhin, ein entsprechendes Wrapper-Skript z. B. zusammen mit spawn-fcgi einzusetzen. Sonst erbt der FastCGI-Prozess beim Spawnen UID und GID von seinem Elternprozess, also dem Apachen. Ein dynamisches Wechseln der UID/GID ist übrigens nicht möglich; hierfür wären root-Rechte vonnöten, und FastCGI-Prozesse unter UID 0 laufen zu lassen ist vielleicht keine so gute Idee...

[codepoet]

Vielen Dank erstmal für die Antwort!

Wenn Du möchtest, dass FastCGI-Prozesse mit einem bestimmten User gespawnt werden, kommst Du nicht umhin, ein entsprechendes Wrapper-Skript z. B. zusammen mit spawn-fcgi einzusetzen. Sonst erbt der FastCGI-Prozess beim Spawnen UID und GID von seinem Elternprozess, also dem Apachen. Ein dynamisches Wechseln der UID/GID ist übrigens nicht möglich; hierfür wären root-Rechte vonnöten, und FastCGI-Prozesse unter UID 0 laufen zu lassen ist vielleicht keine so gute Idee...

Das ist nicht ganz korrekt. Eben aus diesem Grund wird ja suexec eingesetzt, welches das SUID-Bit gesetzt hat und "root" gehört.

[daemotron]

FastCGI != CGI :!:

Suexec führt Dateien unter dem User aus, dem die Dateien gehören. Ein FastCGI-Prozess wird aber nicht über die abzuarbeitende PHP-Datei initialisiert, sondern aus suexec-Sicht über den Wrapper, und das auch nur beim Server-Start (in seltenen Fällen auch noch mal später, wenn neue Prozesse nachgespawnt oder alte ersetzt werden müssen). Hast Du denn für jeden virtuellen Host einen eigenen Wrapper, der dem gewünschten VHost-User gehört? Sind GID und UID dieses Users jeweils größer als 10.000? Ist der Wrapper ausführbar?

Das ist nicht ganz korrekt. Eben aus diesem Grund wird ja suexec eingesetzt, welches das SUID-Bit gesetzt hat und "root" gehört.

Falls sich das auf mein Statement zum dynamischen UID-Wechsel von FastCGI-Prozessen bezieht: Doch, das stimmt, denn suexec wird nur aktiv, wenn ein neuer FastCGI-Prozess erzeugt werden muss - und das ist lange nicht bei jedem Request der Fall. suexec kann dank SUID-Bit seinen eigenen UID-Kontext ändern und dann den gewünschten FastCGI-Prozess erzeugen, der UID und GID automatisch vom suexec-Prozess erbt. Dieser kann dann i.d.R. aber seinen Kontext nicht mehr ändern, da FastCGI-Binaries i.d.R. ohne SUID-Bit auf der Platte liegen (was gut so ist) und auch nicht unter Usern mit ausreichender Berechtigung für setuid() und setgid() ausgeführt werden - was ebenfalls gut so ist.

[codepoet]

Suexec führt Dateien unter dem User aus, dem die Dateien gehören.

Soweit klar.

Ein FastCGI-Prozess wird aber nicht über die abzuarbeitende PHP-Datei initialisiert, sondern aus suexec-Sicht über den Wrapper, und das auch nur beim Server-Start (in seltenen Fällen auch noch mal später, wenn neue Prozesse nachgespawnt oder alte ersetzt werden müssen).

Ebenfalls ACK (nur, dass der Wrapper natürlich nicht beim Server-Start direkt, sondern erst beim ersten Request konsultiert wird).

Hast Du denn für jeden virtuellen Host einen eigenen Wrapper, der dem gewünschten VHost-User gehört?

Ist zwar erst der erste Host, der so konfiguriert wird. Aber das Setup ist so aufgebaut, ja (inkl. einer eigenen "php.ini").

Sind GID und UID dieses Users jeweils größer als 10.000? Ist der Wrapper ausführbar?

Yupp. Aus diesem Grund habe ich das "suexec" ja extra mit diesen Parametern erstellt.

Das ist nicht ganz korrekt. Eben aus diesem Grund wird ja suexec eingesetzt, welches das SUID-Bit gesetzt hat und "root" gehört.

Falls sich das auf mein Statement zum dynamischen UID-Wechsel von FastCGI-Prozessen bezieht: Doch, das stimmt, denn suexec wird nur aktiv, wenn ein neuer FastCGI-Prozess erzeugt werden muss - und das ist lange nicht bei jedem Request der Fall. suexec kann dank SUID-Bit seinen eigenen UID-Kontext ändern und dann den gewünschten FastCGI-Prozess erzeugen, der UID und GID automatisch vom suexec-Prozess erbt. Dieser kann dann i.d.R. aber seinen Kontext nicht mehr ändern, da FastCGI-Binaries i.d.R. ohne SUID-Bit auf der Platte liegen (was gut so ist) und auch nicht unter Usern mit ausreichender Berechtigung für setuid() und setgid() ausgeführt werden - was ebenfalls gut so ist.

Moooment, ich glaube wir reden etwas andeinander vorbei ...
Darüber, dass das "suexec" dafür sorgt, dass das entsprechende FastCGI-Skript mit den gewünschten Rechten ausgeführt wird sind wir uns einig. Da es sich in diesem Fall ja um den PHP-CGI-Wrapper handelt muss dieser seinen Kontext ja auch nicht erneut ändern.

Egal ... Für mich scheint das Problem auch irgendwo anders zu liegen, da ich im "suexec"-Log auch nichts vorfinde, ergo scheint dieser nicht mal angeworfen zu werden. Kann es sein, dass der Apache beim ausführen des Wrappers unter anderer UID Probleme hat bzw. wie kann ich das debuggen (werd jetzt erstmal das Loglevel hochschrauben)? Wie gesagt: Alles läuft ohne Probleme (also inkl. des Wrapper) solange, bis ich auf "suexec" umschalte.

[daemotron]

OK, dann reden wir jetzt von derselben Sache

Hast Du suexec denn zusammen mit Apache aus den Ports gebaut?

Hmm, wenn ein höherer Loglevel nichts zutage fördert, wäre ggf. interessant, ob das Problem nur innerhalb eines Jails besteht bzw. mit welchen Einschränkungen Jails bei Dir laufen (sysctl -a | grep -i jail) - vorstellen kann ich mir zwar nicht, dass es einen Einfluss hat, aber wer weiß...

Ansonsten - passen die Rechte für die Verzeichnisse, in denen die FastCGI-Sockets erstellt werden? Die werden ja erst nach dem Privilege Drop angelegt, ergo braucht der FastCGI-User dort Schreibrechte (750 oder so), und www sollte lesenden Zugriff haben (würd ich über die Gruppe regeln).

[codepoet]

Hast Du suexec denn zusammen mit Apache aus den Ports gebaut?

Yupp ...

/etc/make.conf

Code: Select all

.if ${.CURDIR:M*/www/apache22*}
  WITH_BERKELEYDB=db42

  WITH_DAV_MODULES=yes
  WITH_SSL_MODULES=yes
  WITH_SUEXEC_MODULES=yes

  SUEXEC_DOCROOT=/usr/local/www/virtual
  SUEXEC_SAFEPATH=/usr/local/bin:/usr/bin:/bin
  SUEXEC_LOGFILE=/var/log/httpd-suexec.log
  SUEXEC_UIDMIN=10000
  SUEXEC_GIDMIN=10000
  SUEXEC_UMASK=027
.endif

Hmm, wenn ein höherer Loglevel nichts zutage fördert, wäre ggf. interessant, ob das Problem nur innerhalb eines Jails besteht bzw. mit welchen Einschränkungen Jails bei Dir laufen (sysctl -a | grep -i jail) - vorstellen kann ich mir zwar nicht, dass es einen Einfluss hat, aber wer weiß...

Bin noch nicht dazu gekommen, aber mal sehen was das Logging so sagt.

Zur Jail-Config ...

Code: Select all

security.jail.jailed: 0
security.jail.jail_max_af_ips: 255
security.jail.mount_allowed: 0
security.jail.chflags_allowed: 1
security.jail.allow_raw_sockets: 1
security.jail.enforce_statfs: 2
security.jail.sysvipc_allowed: 1
security.jail.socket_unixiproute_only: 0
security.jail.set_hostname_allowed: 1

Ansonsten - passen die Rechte für die Verzeichnisse, in denen die FastCGI-Sockets erstellt werden? Die werden ja erst nach dem Privilege Drop angelegt, ergo braucht der FastCGI-User dort Schreibrechte (750 oder so), und www sollte lesenden Zugriff haben (würd ich über die Gruppe regeln).

Und irgendwie habe ich die ganze Zeit das Gefühl, dass genau da irgendwo der Hund begraben liegt. Die Verzeichnisrechte habe ich testweise mal "sehr großzügig" gestaltet ... und wenn ich das Verzeichnis beobachte wird auch tatsächlich der Socket erstellt, allerdings so ...

Code: Select all

srwx------  1 www  wheel  0 Apr 23 16:26 36083.1

Daher ja auch meine Frage im Ursprungspost wie genau der Ablauf bei einem solchen Request eigentlich ist. Offensichtlich wird ja doch erst der FastCGI-Socket erstellt und dann (per suexec) der Wrapper angeworfen, welcher dann natürlich sein Ergebnis nicht über den Socket zurückgeben kann.

[daemotron]

<OT>

Code: Select all

security.jail.sysvipc_allowed: 1

Ist das so beabsichtigt? Das reißt nämlich ein hübsches Loch in die solide Jail-Mauer (siehe http://www.rootforum.org/wiki/FreeBSD_J ... sicherheit)
</OT>

Und irgendwie habe ich die ganze Zeit das Gefühl, dass genau da irgendwo der Hund begraben liegt. Die Verzeichnisrechte habe ich testweise mal "sehr großzügig" gestaltet ... und wenn ich das Verzeichnis beobachte wird auch tatsächlich der Socket erstellt, allerdings so ...

Code: Select all

srwx------  1 www  wheel  0 Apr 23 16:26 36083.1

Ganz eindeutiges Iiihhhhhh!!! Nee, so sollte das nich aussehen, das. Da kann ich mir allerdings auch keinen Reim drauf machen :?

[codepoet]

<OT>

Code: Select all

security.jail.sysvipc_allowed: 1

Ist das so beabsichtigt? Das reißt nämlich ein hübsches Loch in die solide Jail-Mauer (siehe http://www.rootforum.org/wiki/FreeBSD_J ... sicherheit)

In diesem Fall ist das OK, da die Zugriffsmöglichkeiten auf das System sowieso recht beschränkt sind. Im Prinzip dienen die Jails primär der Strukturierung und Wartbarkeit des Systems.
</OT>

Und irgendwie habe ich die ganze Zeit das Gefühl, dass genau da irgendwo der Hund begraben liegt. Die Verzeichnisrechte habe ich testweise mal "sehr großzügig" gestaltet ... und wenn ich das Verzeichnis beobachte wird auch tatsächlich der Socket erstellt, allerdings so ...

Code: Select all

srwx------  1 www  wheel  0 Apr 23 16:26 36083.1

Ganz eindeutiges Iiihhhhhh!!! Nee, so sollte das nich aussehen, das. Da kann ich mir allerdings auch keinen Reim drauf machen :?

Dank dir trotzdem schonmal!

[Roger Wilco]

Lies mal den ersten Satz unter Using suEXEC und dann schau dir deine Konfiguration bezüglich dieser Direktive nochmal an.

[codepoet]

Lies mal den ersten Satz unter Using suEXEC und dann schau dir deine Konfiguration bezüglich dieser Direktive nochmal an.

Hmmm ... Hab' das durchaus gelesen. Stehe ich jetzt auf'm Schlauch oder hast du den Thread nicht gelesen?
Meinst du, dass ich das auskommentiert habe?

[Roger Wilco]

Meinst du, dass ich das auskommentiert habe?

Ja. Und dass du dich dann wunderst, dass nichts in deinem SuExec Log steht und die Berechtigung auf den Socket des FastCGI-Interpreters dem Benutzerkontext des Apache httpd entsprechen.

[codepoet]

Meinst du, dass ich das auskommentiert habe?

Ja. Und dass du dich dann wunderst, dass nichts in deinem SuExec Log steht und die Berechtigung auf den Socket des FastCGI-Interpreters dem Benutzerkontext des Apache httpd entsprechen.

Wie gesagt ... Oben im Thread steht doch, dass die Probleme erst beginnen, sobald ich das einkommentiere. Die komplette Konversation schildert doch die Versuche nachdem genau das passiert ist.

[Roger Wilco]

Code: Select all

srwx------  1 www  wheel  0 Apr 23 16:26 36083.1

Ganz eindeutiges Iiihhhhhh!!! Nee, so sollte das nich aussehen, das. Da kann ich mir allerdings auch keinen Reim drauf machen :?

Das ist schon richtig so. Die von mod_fcgi erstellten Sockets im SocketPath haben die Berechtigungen des Webservers. Irgendwie muss der Apache httpd ja noch darauf zugreifen können. Die konkreten PHP-Prozesse laufen allerdings unter jeweils einem eigenen Benutzer.

Was passiert, wenn du dein Wrapper-Skript in dem Jail mit dem Benutzer ausführst, in dessen Kontext das ganze auch später laufen soll?

[codepoet]

Code: Select all

srwx------  1 www  wheel  0 Apr 23 16:26 36083.1

Ganz eindeutiges Iiihhhhhh!!! Nee, so sollte das nich aussehen, das. Da kann ich mir allerdings auch keinen Reim drauf machen :?

Das ist schon richtig so. Die von mod_fcgi erstellten Sockets im SocketPath haben die Berechtigungen des Webservers. Irgendwie muss der Apache httpd ja noch darauf zugreifen können. Die konkreten PHP-Prozesse laufen allerdings unter jeweils einem eigenen Benutzer.

Was passiert, wenn du dein Wrapper-Skript in dem Jail mit dem Benutzer ausführst, in dessen Kontext das ganze auch später laufen soll?

Funktioniert einwandfrei. Habe testweise ein "<?php phpinfo(); ?>" an den Wrapper gepiped und bekomme den korrekten Output. Da kann der Fehler - zumindest vermute ich das - auch nicht liegen, da ich ansonsten ja wenigstens im suexec-Log etwas vorfinden sollte (dass die Anfrage bearbeitet wird), aber soweit kommt es ja gar nicht.

[Roger Wilco]

Erhöhe das LogLevel deines Apache httpd auf debug. Möglicherweise findet sich dann in den Logs ein Hinweis auf die Ursache. Funktioniert das Ganze eigentlich außerhalb des Jails?