suPHP und UserDirs

[begga]

Hallo,

ich habe PHP 4.3.2 mit suphp-0.2.3 am Laufen.
Für reguläre Virtual Hosts funktioniert auch alles wunderbar.
Einzig mit den UserDirs habe ich ein Problem.
Im Hauptweb ist /usr/local/apache/htdocs als Document-Root eingestellt.
Ein Benutzer liegt z.B. hier:
/home/begga/htdocs
Wenn ich jetzt meine URL für das Benutzerweb aufrufe (http://localhost/~begga/)
Dann bekomme ich einen 500er und im suPHP.log steht drin:

Code: Select all

[error] Script /home/begga/htdocs/index.php is not in the DOCUMENT_ROOT (/usr/local/apache/htdocs)

Mir ist die Meldung und deren Bedeutung durchaus bewusst.
Aber deshalb kann ich doch nicht das Standard-Doc-Root auf /home legen. :roll:
Testweise hab ich das zwar mal gemacht, und es funktioniert dann auch, aber das kanns ja nicht wirklich sein... :(
Was kann ich tun um die User-Homepages auch über suPHP laufen zu lassen?

[majortermi]

Das geht so nicht, wie du es dir vorstellst: suPHP überprüft, ob ein PHP-Skript auch tatsächlich im Document-Root liegt, so dass "Alias"-Direktiven nicht funktionieren. Dadurch wird verhindert, dass von außen auf Skripte zugegriffen wird, auf die eigentlich kein Zugriff möglich sein sollte.

Die einzige Möglichkeit besteht darin, den suPHP-Quellcode dahingehend zu ändern, dass nicht mehr auf DOCUMENT_ROOT geprüft wird, das wäre mir persönlich aber zu gefährlich.

Bessere Lösung: Für jeden User einen eigenen VHost anlegen.

[begga]

Irgendwie hab ich mir sowas schon gedacht... :(

Für jeden User einen VHost anzulegen wird so nicht funktionieren.
Da bräuchte ich mehrere hundert VHosts, ABER:
Es handelt sich um einen Intranet-Server wo ich keine Möglichkeit habe am DNS-Server Subdomains einzurichten bzw. einen Wildcard-Eintrag zu machen.

Gibts da irgendwelche anderen Alternativen?
Könnte ich z.B. mit mod_rewrite

Code: Select all

localhost/begga

nach

Code: Select all

begga.localhost

umschreiben lassen?
Und das müsste dann ja ohne passenden DNS-Eintrag funktionieren, oder?

[majortermi]

Für jeden User einen VHost anzulegen wird so nicht funktionieren.
Da bräuchte ich mehrere hundert VHosts, ABER:
Es handelt sich um einen Intranet-Server wo ich keine Möglichkeit habe am DNS-Server Subdomains einzurichten bzw. einen Wildcard-Eintrag zu machen.

Du bist zwar für die Administration des Webservers zuständig, hast aber keine Möglichkeit DNS-Einträge vorzunehmen, bzw. von den zuständigen Leuten vornehmen zu lassen? Da würde ich mich an deiner Stelle mal über die besch... Verwaltungsstruktur in eurem Netzwerk beschweren.

Eine Lösung mit Rewrite-Rules ist prinzipiell möglich, aber eher als "böser Hack" zu bezeichnen (du müsstest dazu die Subdomains in der /etc/hosts eintragen und dann über mod_rewrite mit mod_proxy auf diese umleiten).
Mir ist aber gerade noch eine Möglichkeit eingefallen: Du legst den DOCUMENT_ROOT auf die gleiche Partition wie die Home-Verzeichnisse und erstellst dann im DOCUMENT_ROOT Hardlinks, die auf die Verzeichnisse der Benutzer zeigen (kannst du ja durch ein Skript machen lassen, um dir nicht die Finger Wund zu schreiben).

[begga]

Du bist zwar für die Administration des Webservers zuständig, hast aber keine Möglichkeit DNS-Einträge vorzunehmen, bzw. von den zuständigen Leuten vornehmen zu lassen? Da würde ich mich an deiner Stelle mal über die besch... Verwaltungsstruktur in eurem Netzwerk beschweren.

Mit den besch... Strukturen in unserem Netz hast du gar nicht so unrecht. ;)
Das kommt aber wohl daher dass wir über 250.000 Rechner zu verwalten haben und die Rechnernamen aus verwaltungstechnischen Gründen in einer Datenbank stehen.
Ã?ber Nacht werden nun alle örtlichen DNS-Datenbanken aus dieser einen großen Datenbank gespeist, und alle "Ã?nderungen" somit wieder überschrieben.
Und in dieser gemeinsamen Datenbank können prinzipiell nur Hostnamen gepflegt werden.
Man kannn zwar auch Alias-Namen anlegen, die aber gewissen Beschränkungen unterliegen (z.B. Anzahl & Art der Zeichen)
Das macht richtige Subdomains für mich unbrauchbar.
Zumal alle von Hand gepflegt werden müssten und bei mir ständig Benutzer dazu kommen und wieder welche wegfallen.
Und dieser Aufwand ist über Alias-Namen nicht tragbar.

Ich wollte ja zuerst einen Wildcard-DNS-Eintrag mit dem ich dann quasi alles so machen könnte wie ich will.
Gerade in Bezug auf unsere vielen Projekte und User wäre das eine feine Sache.
Geht aber leider aus den og. Gründen nicht.
Der Eintrag würde über Nacht wieder gelöscht werden :(

Aber die Idee mit den Hardlinks ist genauso simpel wie genial; werde ich am Montag mal versuchen wenn ich wieder auf der Arbeit bin. ;)

[majortermi]

Mit den besch... Strukturen in unserem Netz hast du gar nicht so unrecht. ;)
Das kommt aber wohl daher dass wir über 250.000 Rechner zu verwalten haben und die Rechnernamen aus verwaltungstechnischen Gründen in einer Datenbank stehen.
Ã?ber Nacht werden nun alle örtlichen DNS-Datenbanken aus dieser einen großen Datenbank gespeist, und alle "Ã?nderungen" somit wieder überschrieben.
Und in dieser gemeinsamen Datenbank können prinzipiell nur Hostnamen gepflegt werden.

Ich kann das Problem sehr gut nachvollziehen, da ich es in einem ähnlichen Zusammenhang kenne. Sobald man eben wirklich große Zones hat und die aus Datenbanken speißen muss, lässt die Flexibilität des DNS stark nach. Natürlich kann man prinzipiell die Skripte ändern, aber wer nimmt schon persönlich das Risiko in Kauf, das entsteht, wenn man an für den Netzwerkbetrieb elementaren Tools herumpfuscht, sicher ist da ja nur eins: Wenn es gut geht, haben es die Leute nach zwei Tagen wieder vergessen, aber wenn es schief geht und das Netzwerk dadurch lahm gelegt wird, bekommt man ordentlich eins auf den Deckel :evil:

Naja, mit den Hardlinks sollte du jetzt ja eine praktikable Lösung haben. Und zum Thema DNS: Registrier doch einfach an den Standard-Tools vorbei irgendeine Domain und trage Nameserver ein, die du selbst administrieren kannst. Dann kannst du alle Sachen, bei denen du ein flexibles DNS brauchst, darüber abwickeln.

[begga]

So, das mit den Links hat geklappt.
Musste zwar Softlinks nehmen da man mit Hardlinks wohl keine Verzeichnisse linken kann, aber egal.

Jetzt hab ich aber ein anderes (größeres) Problem bei dem ich auf keine Lösung komme:

Ich kann über PHP auf die Daten eines anderen Benutzers zugreifen!
Und das ist ja wohl keineswegs Sinn von suPHP. :(

Zuerstmal die Fakten:

Inhalt von /home/webs:

Code: Select all

drwx--x---    4 tt-cca   www          4096 Aug 21 07:58 tt-cca/
drwxr-x---    4 tt-ccb   www          4096 Aug 21 07:57 tt-ccb/

Inhalt von /home/webs/tt-cca:

Code: Select all

drwx--x---    4 tt-cca   www          4096 Aug 21 07:58 ./
drwxr-xr-x    7 root     root         4096 Aug 20 09:32 ../
-rw-------    1 tt-cca   users          92 Aug 20 10:53 .bash_history
drwxr-xr-x    2 tt-cca   www          4096 Aug 21 08:02 htdocs/
drwx------    2 tt-cca   users        4096 Aug 20 10:02 logs/
-rw-------    1 tt-cca   users       24472 Aug 20 09:34 php.ini
-rw-------    1 tt-cca   users         795 Aug 21 07:58 .viminfo

Inhalt von /home/webs/tt-cca/htdocs:

Code: Select all

drwxr-xr-x    2 tt-cca   www          4096 Aug 21 08:02 ./
drwx--x---    4 tt-cca   www          4096 Aug 21 07:58 ../
-rw-------    1 tt-cca   users         153 Aug 20 10:48 file.php
-rw-------    1 tt-cca   users         113 Aug 20 09:41 index.php
-rw-------    1 tt-cca   users         797 Aug 21 07:58 inhalt.php

Apache läuft als www/www
und PHP 4.3.2 als CGI

Ich kann mit der Datei inhalt.php Dateien im htdocs-Verzeichnis von tt-ccb aufrufen!!
Aber das komische ist: das geht nur wenn PHP über http ausgeführt wird.
Wenn ich das Skript über die Konsole mit

Code: Select all

php inhalt.php

aufrufe bekomme ich, so wie es sein soll, auf das home-Verzeichnis des Benutzers tt-ccb "Permission denied"

Die Benutzer tt-cca und tt-ccb sind Mitglieder in der Gruppe users
Und im suPHP-Logfile steht das drin:

Code: Select all

[Thu Aug 21 10:25:04 2003] [info] /home/webs/tt-cca/htdocs/inhalt.php executed as user tt-cca (509), group users (100)

Aber wenn der das Skript wirklich als tt-cca in der Gruppe users ausführt,
wie kann ich dann auf die Daten des anderen zugreifen??
Dessen home-dir ist doch dadurch geschützt dass

Code: Select all

drwx--x---    4 tt-ccb   www          4096 Aug 21 07:58 tt-ccb/

auf den Ordner nur der Benutzer tt-cca oder dir Gruppe www zugreifen darf. :roll:

Also würde ich sagen stimmt was an der Konfiguration von suPHP oder von Apache nicht. Ich komme aber nicht drauf. :(
Wer kann helfen?

[kase]

Vielleicht haben die Files von Mr B ein +r für alle, was gar nicht so unnormal wäre. Immerhin muss ja der Apache die auch lesen können.

Normalerweise löst man das Problem, indem man für jeden User einen vhost mit einer eigenen PHP.ini anlegt suPHP_ConfigDir = oder so ähnlich. Dann kann man einfach ganz bequem für jeden User das open_basedir festlegen, und somit ein vordringen in fremde Verzeichnisse verhindern.

[begga]

Vielleicht haben die Files von Mr B ein +r für alle, was gar nicht so unnormal wäre. Immerhin muss ja der Apache die auch lesen können.

Klar ist das so.
Aber:
Der Apache läuft als www/www
und darf somit in das Verzeichnis hier wechseln und dort lesen:

Code: Select all

drwxr-x---    4 tt-ccb   www          4096 Aug 21 07:57 tt-ccb/

Die PHP-Skripte selbst werden als tt-cca/users ausgeführt.
Wieso darf das PHP-Skript überhaupt in das og. Verzeichnis wechseln??
Ã?ber die Konsole als tt-cca darf ichs doch auch nicht. :roll:
tt-cca/users hat doch komplett gar nix mit tt-ccb/www zu tun. :!:

Normalerweise löst man das Problem, indem man für jeden User einen vhost mit einer eigenen PHP.ini anlegt suPHP_ConfigDir = oder so ähnlich. Dann kann man einfach ganz bequem für jeden User das open_basedir festlegen, und somit ein vordringen in fremde Verzeichnisse verhindern.

Lies dir mal meine Beiträge da oben durch.
Dann weisst du warum es für einzelne Benutzer keine vHosts gibt.

[majortermi]

Das ist ein Problem mit den "supplementary groups" unter Linux (und den meisten anderen *NIX-Systemen). In der nächsten Version ist das Problem behoben, indem die "supplementary groups" richtig gesetzt werden.
Wann das neue Release kommt, kann ich noch nicht genau sagen, weil das neue Release die GNU autotools als Buildsystem benutzen soll, ich habe momentan aber noch ziemliche Probleme mit autoconf und automake. Wenn jemand von den Tools Ahnung hat, soll er sich bitte mal bei mir melden...

[begga]

Ich bekomme noch die Krise... :evil:
Da hab ich mir überlegt wenn das mit der Gruppe so nicht funktioniert mach ichs halt andersrum:

Code: Select all

drwx---r-t    4 tt-cca   users        4096 Aug 21 12:08 tt-cca/

So darf der Apache über "others" in das Verzeichnis rein und alle in der Gruppe users bleiben draussen.
Das funktioniert so auch.
Nur jetzt funktionieren die symbolischen Links auf die UserDirs nicht mehr :(

Bzw. funktioniert es schon nicht wenn einfach nur eine Datei in tt-cca liegt dessen Besitzer ein anderer ist als tt-cca, so z.B.:

Code: Select all

-rw-r--r--    1 tt-cca   users        1380 Mai  9 10:06 index.php
-rw-r--r--    1 tt-ccb   users          19 Aug 22 08:49 test.php

Die index.php funktioniert ordnungsgemäß
Nur bei Aufruf der Datei test.php bekomme ich einfach nur die Meldung:

Code: Select all

No input file specified. 

Und genau das ist wohl auch das Problem der UserDirs die über symbolische Links aufgerufen werden.
Die Links liegen nämlich im Hauptweb das tt-cca/users hat
und die zeigen auf Verzeichnisse mit der Berechtigung username/users
Und dann kommt eben auch diese Meldung "No input file..."

Aber lt. dem Logfile von suPHP wird die Datei richtig ausgeführt:

Code: Select all

[Fri Aug 22 09:43:21 2003] [info] /home/webs/tt-cca/htdocs/test.php executed as user tt-ccb (509), group users (100)

Das geile ist: Wenn ich der Datei test.php die Gruppe www (also die Apache-Gruppe) zuweise führt er die Datei anstandlos aus.
Nur habe ich da ja wieder mein Sicherheitsproblem...

Ich hänge jetzt schon fast ne Woche an dem Problem und drehe mich nur im Kreis.
Wenn das so weitergeht latsch ich noch ins Rechenzentrum und trete den Server aus dem Leben :!:

Hat niemand eine Idee was ich noch machen könnte?

[majortermi]

Hat niemand eine Idee was ich noch machen könnte?

Ja, auf das nächste suPHP-Release warten. Die Probleme mit Autoconf konnten inzwischen weitgehendst gelöst werden, indem nicht mehr Automake zur Erzeugen der Makefiles benutze wurde, sondern diese von Hand geschrieben. Die Chancen, das in absehbarer Zeit (also den nächsten 1-2 Monaten) ein neues Release kommt, sind dadurch deutlich angestiegen.

[begga]

[...]
Ja, auf das nächste suPHP-Release warten.
[...]

Mhh, der Server geht spät. am 01.09. produktiv. Da führt kein Weg dran vorbei.
Im Moment bastel ich dann wohl die Projekte über suPHP und die UserDirs über suEXEC

Aber von suPHP gabs doch schon ewig kein Update mehr, oder?
Ich bin davon ausgegangen dass das Projekt eingestellt worden ist. ;)

[majortermi]

Mhh, der Server geht spät. am 01.09. produktiv. Da führt kein Weg dran vorbei.
Im Moment bastel ich dann wohl die Projekte über suPHP und die UserDirs über suEXEC

Wie schnell sind solche Datumsangaben wieder überholt: Heute ist das neue suPHP-Release herausgekommen...

[begga]

Cool. Wenn man der Homepage glauben schenken darf soll das Problem mit den Groups tatsächlich behoben sein. 8)
Muss ich gleich nächste Woche mal testen. ;)
Aber sag mal, hast du irgendwas mit dem Projekt zu tun weil du da immer recht genau Bescheid weisst?? :roll: