frankx: Die 25 gefährlichsten Programmierfehler

Beitrag lesen

Hellihello Christoph,

Warum PHP nicht als Modul?

Weil ich die verschiedenen Projekte, die jeweils ein VHost sind, gerne voneinander trenne: Jedes Projekt hat eigene Folder für Sessiondateien, Uploads, Logs, etc.

Das geht demnach nicht, wenn PHP ein Modul ist?

Jedes Projekt wird als eigener User behandelt.

Das ist ja Voraussetzung für suexec, oder? Die Skripte stammen vom FTP-User und können deshalb nur Skripte einbinden, die dem selben User gehören (es sei denn, man konfiguriert das absichlich anders)?

Zusätzlich ist PHP als Modul (bzw. einige der Extensions) nicht threadsicher, was ich für meinen Worker-MPM-Apache aber benötige.

Das ist dann also wirklich auch das no-go, oder?

Abschließend ist der Betrieb als FastCGI auch noch deutlich performanter als der Betrieb als CGI oder Modul.

Du hast mit MPM und FastCGI also einen merklich schnelleren(=effizienteren) Server?

Und warum suexec.

Hauptsächlich zur Nutzertrennung. Ansonsten siehe Manual.

"However, if suEXEC is improperly configured, it can cause any number of problems and possibly create new holes in your computer's security."

Das hatte mich jetzt etwas abgeschreckt. Wenngleich das Plesk auf einem virtuellen Server das eben von sich aus mitbringt. In Kombination mit open_base_dir, wenn ich das recht erinnere.

Geht es schlimmer als gar keine Nutzertrennung? suexec bewahrt dich vor den größten Problemen (Skripte unter root laufen lassen). Dafür ist die Konfiguration etwas umfangreicher.

Ich dachte, die Skripte würden sonst unter dem Apachenutzer laufen? Also wwwrun:psaserv (unter Suse/Plesk).

Ja. Aber da open_basedir genauso wenig wie der safe_mode hunderprozentig funktioniert, verlasse ich mich doch eher auf sorgfältig vergebene Rechte.

Dank und Gruß,

frankx

--
tryin to multitain  - Globus = Planet != Welt