php ignoriert user - wie macht ihr es?

[desperado]

Hi all,

bei php gibts ja das Problem dass es, solange es nicht als cgi rennt, sich einen Dreck um die User/Group Definitionen für VirtualDomains in der HTTPD-Config des Apache schert. Das hat ja zur Folge, dass immer der Haupt-User verwendet wird. Lästig wird das, wenn man für diverse Webpräsenzen eigene ftp-Accounts hat, zum Ã?bertragen der Dateien. Hier alles über die Permissions der Group zu machen ist wohl nicht das Gelbe vom Ei.

Daher meine Frage: Wie handhabt ihr das? Laßt ihr alle php als cgi laufen? Wenn, was hat das für Nachteile? Wenn nicht, wie geht es anders?

Thx!

[oxygen]

Es gibt genügen andere Möglichkeiten hier mal ein paar Worte mit denen du die Suchfunktion oder Google füttern kannst:
SuPHP
SuExec
fastcgi
metux

[desperado]

SuPHP

Theoretisch schön, aber läuft nicht mit mod_php zusammen :-(

SuExec

Dazu muss php ja auch als CGI laufen

fastcgi

müsste ich mich nochmal mit beschäftigen, war mir etwas zu komplex, wenn ich mich richtig erinnere

metux

nur für Apache 2 soviel ich weiss

[desperado]

Hi,

ich hab mich nun doch entschlossen, php als cgi laufen zu lassen.

Nun mein Problem: Ich wollte via phpinfo() herausfinden, mit welchen Optionen das aktuelle cli-php kompliliert ist. Leider spuckt aus unerfindlichen Gründen phpinfo() nicht das sonst übliche "Configure Command" aus. Weiss jemand warum bzw. wie ich an die ganzen Optionen komme?

[Anonymous]

Die Fehler kommen durch den safe_mode, wobei das jeweilige Script immer als Apacheuser wwwrun ausgeführt wird, aber nicht die Rechte des eigenen Users bekommt. Für mich ist der safe_mode einfach buggy und sollte nochmals überarbeitet werden.

Es gibt dafür eine Lösung - aber erst ab der PHP-Version 4.3.5:

http://www.titov.net/safemodepatch

Vielleicht hilft dir das ja. Mir leider - noch - nicht, da ich erst auf das neuere PHP wechseln müßte. Ist mir zZt. jedoch zu heiß.

Hat Jemand Erfahrungen mit der Version PHP 5.0 ? Tritt dieser Fehler dort auch noch auf ?

[rob k]

SuExec

Dazu muss php ja auch als CGI laufen

Ã?hm, nein. Das funzt auch mit mod_php prima.

[sascha]

SuExec

Dazu muss php ja auch als CGI laufen

Ã?hm, nein. Das funzt auch mit mod_php prima.

Aber nicht mit PHP Scripten.

[rob k]

Warum denn nicht?
Ich hab auf mehreren Servern Apache + suExec + PHP4 als Modul am laufen ....

[mmg-media]

Warum denn nicht?
Ich hab auf mehreren Servern Apache + suExec + PHP4 als Modul am laufen ....

Deswegen

What is suEXEC?
The suEXEC feature -- introduced in Apache 1.2 -- provides Apache users the ability to run CGI and SSI programs under user IDs different from the user ID of the calling web-server. Normally, when a CGI or SSI program executes, it runs as the same user who is running the web server.

Used properly, this feature can reduce considerably the security risks involved with allowing users to develop and run private CGI or SSI programs. However, if suEXEC is improperly configured, it can cause any number of problems and possibly create new holes in your computer's security. If you aren't familiar with managing setuid root programs and the security issues they present, we highly recommend that you not consider using suEXEC.

http://httpd.apache.org/docs/suexec.html

[rob k]

Ok Du hast Recht!
Ich nehm alles zurück und behaupte das Gegenteil! :)

Allerdings frage ich mich wie das dann bei PERL mit suEXEC funzt? Oder greift das da nich? Weil /bin/perl gehört doch auch nich dem User, der es dann ausführt....

[Joe User]

man SUID

[rob k]

Kannst Du evtl etwas konkreter werden?

No manual entry for suid

[sascha]

Bei deinen Perl Scripten gibst du in der ersten Zeile immer den Pfad zum Interpreter (/usr/bin/perl - eine sog. "Shebang Zeile") an. Das gleiche kannst du natürlich auch mit PHP machen. Allerdings müssen sich die Scripte dann in einem Verzeichnis befinden, in dem CGI erlaubt ist (cgi-bin) und du musst bei jedem PHP Script diese Ã?nderung vornehmen.

[rob k]

Ja das ist mir schon klar. Und greift in diesem Fall suExec nicht oder wie?

[sascha]

In dem von mir beschriebenen Fall schon.

[desperado]

Irgendwie sehe ich inzwischen vor lauter Bäumen den Wald nicht mehr :-(

Letztlich bleibt ja nix anderes als PHP als CGI zu integrieren. Oje...

Irgendwie traue ich mich da jetzt nicht ran. Gibts vielleicht irgendwo ein brauchbares Howto dafür und vor allem: Was muss ich alles sichern, damit ich im Notfall die aktuelle Konfiguration wieder herstellen kann?

[rob k]

Du musst nichts weiter sichern. Du kommentierst nur das Modul aus der httpd.conf aus und intergrierst die Aufrufe für PHP-CGI.

Howto's für PHP-CGI gibts massen, afaik sogar auf php.net und ansonsten bei Google.

Sichern kannst Du ja die httpd.conf und php.ini trotzdem vorher :)

[desperado]

So ganz schlau werde ich daraus nicht. Was ich bisher gelesen habe sagt, dass das PHP-Binary im cgi-bin liegen muss, oder wenn woanders, dass

Code: Select all

#!/path_to_php/php

in der 1. Zeile der php-Scripts stehen muss.
Das geht aber doch auch anders, zumindest war es früher bei meinem Hoster so, wo php als CGI lief und weder im cgi-bin lag noch ich den Pfad des Binaries angeben musste..

btw: da ich php wohl neu komplieren muss: Wie finde ich denn die configure-commands raus, wenn phpinfo() sie nicht ausspuckt?

[sascha]

Ja sicher geht es auch anders. Wenn du deine Scripte nicht ändern willst, dann nimm suPHP oder gleich Metux.

Ach ja eine dritte Möglichkeit ist mir gerade wieder eingefallen: http://www.pookey.co.uk/php-security.xml