PHP-k futtatása tulajdonosként hogyan? (suPHP cseréje mire?)

Internet: PHP, CGI, stb.

Sziasztok!

Debian Wheezyről frissítek Jessie-re. Apache + PHP + MySQL kliens (szerver máshol van).
A kérdésem az lenne, hogy tudtok-e valami jó alternatívát a suPHP-ra. Az új verzióban már nincs, és fontos, hogy a szerveren lévő két felhasználó a saját PHP fájljait a saját nevében futtassa Apache alatt.

Amiket eddig találtam:

mod_php
Egyszerű, és sokan használják, de ha jól tudom nem megoldott az, hogy a tulajdonos futtassa a PHP-ket

fastcgi
Csak a non-free tárolóban van benne, amit nem szeretnék használni.

Mit javasoltok? Esetleg valami más megoldás?

  • 3397 megtekintés

( xian v | 2016. 03. 02., sze – 12:39 )

php-fpm
Debian-ban php5-fpm a csomag neve.

( mauzi v | 2016. 03. 03., cs – 16:29 )

Nekem ezekkel a PHP-központú megoldásokkal mindig az a bajom, hogy az oké, hogy a PHP fájlok a megadott júzerből futnak, de ettől még nem oldottuk meg az alábbi két, nem jelentéktelen problémát:

1.) A nem-PHP tartalmaknak (statikus tartalom, etc.) vagy world-readable kell lenni, hogy az Apache ki tudja őket szolgálni, vagy root-ból kell futtatni az Apache-ot. (Esetleg nem rootból, hanem POSIX ACL-ekkel ügyeskedni)

Normális körülmények között ezek kizárva.

2.) Nem megoldás az egyéb aktív tartalmakra, márpedig a világ nem csak PHP-ből áll általában. (Perl, Python, egyéb, gyakran előforduló CGI applikációk)

A régi megoldás ugye a minden felhasználónak saját apache-ot indítunk külön porton, és elé teszünk egy reverse proxy-t, ami kicsit nagyobb overhead a kelleténél,

vagy, esetleg mpm-itk, ha valaki megbízik benne, hogy az URL parser és környéke root-ból fut.

Tud valaki ezeknél jobbat?

> Egyébként nem kell, hogy world readable legyen, elég ha a webszerver tudja olvasni.

Hagyományos POSIX jogosultságokkal nehezen csinálod meg, hogy nem world-readable, de a webszerver tudja olvasni. (Ehhez az kellene, hogy a webszerver az összes létező csoportban benne legyen, ami nem megy - jellemzően 16/32 csoport a limit) A megoldást a POSIX ACL-ek kínálják részben, de annak meg nem teljeskörű a támogatottsága.

> Miért baj, hogy world readable valami, amit amúgy is kiszolgálsz weben?

Mert ezzel elvárod azt, hogy a felhasználód minden fájlra korrekt, fájltípusonként eltérő jogosultságot állítson be. Ez a gyakorlatban lehetetlen. Akármire állítod be az umask-ot/create mask-ot, az az esetek egy részében nem lesz jó.

A documentroot alatt vegyesen vannak nem-érzékeny, statikus HTML fájlok (amiket úgyis kiszolgál az Apache) és érzékeny dinamikus fájlok (védendő programkódok, adott esetben plaintext db kapcsolati adatokkal, stb.)

( Sea-you | 2016. 03. 03., cs – 22:59 )

Ha nincs szukseg redundanciara akkor futtathatod dokkun.