VirtualHost - neuer User setzen

[p2p]

Hallo zusammen!

In der httpd.conf wird ja mittels "User" und "Group" angegeben als welcher Benutzer der Apache laufen soll. Ist es nun möglich in jedem VirtualHost einen anderen "User" und eine andere "Group" anzugeben, d.h. erfolgt ein Zugriff in VHost1 dann wird dieser als User1 ausgeführt, in VHost2 als User2 usw... ?

Gruß und Danke

p2p

[jtb]

such mal nach suExec und suPHP..

Ansonsten kann es AFAIK Apache 2 von Haus aus..

[jamesb]

Apache 1.x läuft troz User- und Group-Angaben in den einzelnen VHosts unter den Rechten, die in der httpd.conf eingestellt sind. Die User- und Group-Angaben beziehen sich eigentlich nur auf SuExec (bzw. SuPHP), welches normalerweise CGI-Scripte ausführt. D.h. html-Dateien werden trozdem unter dem "gesamt-User" gelesen.

Ab Apache 2 ist es allerdings möglich, einen VHost komplett unter anderen Rechten zu starten, so dass auch html-Dateien unter dem mit User/Group eingestellten User gelesen werden.

JamesB

[p2p]

Welchen Namen/Welche Gruppe hat denn der "gesamt User"?

[firefox747]

Standardmäßig läuft der Indianer mit wwwrun:www

[p2p]

gut, danke.

[xm2000]

Apache 1.x läuft troz User- und Group-Angaben in den einzelnen VHosts unter den Rechten, die in der httpd.conf eingestellt sind. Die User- und Group-Angaben beziehen sich eigentlich nur auf SuExec (bzw. SuPHP), welches normalerweise CGI-Scripte ausführt. D.h. html-Dateien werden trozdem unter dem "gesamt-User" gelesen.

heißt das im klartext das mir das bei apache 1.x mit php als modul überhaupt nix bringt ? ich will nämlich das die von php erstellten dateien und order dem kunden gehören und nicht apache - muss ich dafür jetzt echt apache 2.x klarmachen ?

[kahler]

heißt das im klartext das mir das bei apache 1.x mit php als modul überhaupt nix bringt ?

Ja, genau.

muss ich dafür jetzt echt apache 2.x klarmachen ?

Nein, Ã?bersetze PHP nochmal als CGI und benutz suPHP.

ich will nämlich das die von php erstellten dateien und order dem kunden gehören und nicht apache

Genau das macht suPHP und es schützt die enizelnen Kunden voreinander, d.h. Kunde X kann nicht mehr auf die Daten von Kunde Y zugreifen.

[xm2000]

is cgi php nich supa langsam ?

Genau das macht suPHP und es schützt die enizelnen Kunden voreinander, d.h. Kunde X kann nicht mehr auf die Daten von Kunde Y zugreifen

es geht mir mehr darum das man die von php geuppten oda von der gd erstellten dateien per ftp löschen kann ...

[kahler]

is cgi php nich supa langsam ?

Angeblich ist es schon langsamer, als das Apache Modul. Ich habe allerings noch nichts davon gemerkt. Macht also vielleicht 1-2 Prozent aus, wenn überhaupt.

Außerdem gibts für den Apache 2 auch nur ein PHP Modul, das vielleicht den Status Alpha verdient, mehr nicht. Also muss man wieder auf das CGI ausweichen

es geht mir mehr darum das man die von php geuppten oda von der gd erstellten dateien per ftp löschen kann ...

Wie gesagt, die Dateien gehören dann dem Benutzer, für dem auch das Verzeichnis gehört (danach geht suPHP AFAIK). Musst du also nur anpassen, dann kannst du die Dateien auch per FTP wieder löschen.

[majortermi]

is cgi php nich supa langsam ?

Bei mittelmäßig belasteten Sites merkt man nichts davon (kann man z.B. daran sehen, dass selbst große Provider wie 1&1 PHP als CGI laufen lassen).

Wenn es um richtig viele Requests geht, ist mod_php sicher auch nicht das richtige, sondern man sollte besser gleich einen Application-Server verwenden.

[mstuebner]

Apache 1.x läuft troz User- und Group-Angaben in den einzelnen VHosts unter den Rechten, die in der httpd.conf eingestellt sind. Die User- und Group-Angaben beziehen sich eigentlich nur auf SuExec (bzw. SuPHP), welches normalerweise CGI-Scripte ausführt. D.h. html-Dateien werden trozdem unter dem "gesamt-User" gelesen.

Sicher? Denn es steht geschrieben, dass wenn der "Haupt"-Indianer als Root läuft, die VHosts die angegebenen User benutzt.

Natürlich sollte man dann den "Haupt"-Indianer am besten garnicht für externe Zugruffe nutzen, sondern nur VHosts.

[xm2000]

Sicher? Denn es steht geschrieben, dass wenn der "Haupt"-Indianer als Root läuft, die VHosts die angegebenen User benutzt.

sicher ? bei nem normalem confixx system wäre das ja nämlich der fall, da gibts ja nu vhosts - dann wäre das ja die schnellste lösung ? aber is die dann trotz nich externer anbindung wirklich sicher ??

[jamesb]

Sicher? Denn es steht geschrieben, dass wenn der "Haupt"-Indianer als Root läuft, die VHosts die angegebenen User benutzt.

Sicher. Die User/Group-Angaben beziehen sich nur auf SuExec bzw. auf spezielle Module. Mod_PHP gehört da definitiv nicht dazu. Wenn du die VHosts unter den o.g. Angaben laufen lassen willst, ist Apache 2.x nötig, und für den gibt's bis jetzt noch keine 100%ig vernünftige PHP-Lösung (IMHO).

Der "Haupt"-Apache sollte übrigens auch _nie_ unter root laufen, sondern unter einem Apache-User, der fast nirgends Dateien schreiben darf (nur wenn du es ihm explizit erlaubst).

JamesB

[mstuebner]

Sicher. Die User/Group-Angaben beziehen sich nur auf SuExec bzw. auf spezielle Module. Mod_PHP gehört da definitiv nicht dazu. Wenn du die VHosts unter den o.g. Angaben laufen lassen willst, ist Apache 2.x nötig, und für den gibt's bis jetzt noch keine 100%ig vernünftige PHP-Lösung (IMHO).

Der OP schrieb übrigens garnichts von PHP, das kam erst später ins Spiel. Frag ich mich nur, warum die ApacheGroup Dinge entwickelt die man ja auf keinen Fall benutzen soll.

Und BTW: Wenn man den Zugriff auf den Haupt-Apachen sperrt, wo siehst Du dann das Risiko wenn der unter Root läuft?

[jtb]

Ein Apache-Prozess, welcher Clients bedient, wird NIE als root laufen außer man trägt es ausdrücklich in die Config ein.. Apache selber muss aber einen Prozess haben, der als root läuft. Beim Erstellen eines neuen Clients wird dieser aber immer root aufgeben..

[xm2000]

Und BTW: Wenn man den Zugriff auf den Haupt-Apachen sperrt, wo siehst Du dann das Risiko wenn der unter Root läuft?

versteh ich jetzt auch nich so ganz, jetzt aber mal anders gefragt - wie macht ihr das denn mit den php erstelltetn dateien ? wirklich über cgi ?
geht das gut ? ich brauche eine praktikable und sichere lösung für dieses problem - es kommt nämlich ziemlich oft vor und jedesmal die dateien zu chmoden is wirklich keine dauerlösung :(

[kahler]

wie macht ihr das denn mit den php erstelltetn dateien ? wirklich über cgi ?

Ja, bisher die einzige Möglichkeit, Usern den Zugriff auf fremde Dateien zu verbieten (über suPHP)

geht das gut ?

Klar, wieso nicht. Sonst würden es ja nicht so viele und vor allem so große Hoster wie Puretec etc machen.

ich brauche eine praktikable und sichere lösung für dieses problem

suPHP ist beides: praktikabel und sicher.

es kommt nämlich ziemlich oft vor

Was kommt ziemlich oft vor. Bei mir kommt es auch ziemlich oft vor.
Nur was ist es :lol:

[xm2000]

hehe

-> das user über FTP files löschen oder editieren möchten die von php erstellt wurden.

ok doky dann werd ich das mit cgi auch mal ausprobieren ...