ugrás a tartalomhoz

Apache mpm_perchild vs. PHP 5

janoszen · 2007. Jan. 26. (P), 15.31
Sziasztok,

úgy tűnik mostanság szerveres témával terhellek benneteket. Ha sok belőle, szóljatok rám. :)

Szóval, a következő a probléma. Megpróbáltam egy olyan biztonsági modellt összeütni, amelyikben minden felhasználónak a home könyvtárában vannak a publikus domainek. Eddig ok a dolog.

Viszont nem szeretném, ha más felhasználó is (akár shellből akár máshonnan) tudná olvasni azokat a dolgokat, amik nem az övék. Ilyen lehet ugye, az adatbázis jelszó és egyebek.

E célból azt szerettem volna, ha az Apache olyan felhasználó nevével hívja föl az adott dolgot, ami a könyvtár tulajdonosa. Tehát a /home/janos könyvtárban levő dolgokat a VirtualHost segítségével janos usernévvel nézi meg az Apache.

A probléma az, hogy a VirtualHost részben a 2.0-ás Apache már nem támogatja a User direktívát, az mpm_perchild pedig az APT jelentése szerint nem kompatibilis a PHP-vel (mpm_prefork kell neki), ráadásul experimental.

A suexec nem jó megoldás, hiszen az csak a CGI scriptekre érvényes, mint például a PHP-ra.

Mit lehet szerintetek tenni?

J

ui. ha fontos, Ubunturól van szó.
‹ IP visszafordítása több hostnévre Novell és az Apache ›
 ■
1

PHP CGI

janoszen · 2007. Jan. 26. (P), 18.46
Közben rájöttem, hogy nekem CGI-ként kellene telepíteni a PHP-t, de nem nagyon akar összejönni, ha nem akarom a document root alá betenni a PHP-t... Esetleg valakinek van egy megoldása, ami kint tartja a docrooton kívül de azért még lefuttatja?
2

open_basedir for remedy

js · 2007. Jan. 26. (P), 22.49
Az a gond a CGI és fastcgi megoldásokkal, hogy az elsőnek lényegesen alacsonyabb a performanciája (hiszen minden egyes kérésre indít egy php-t), a másodiknak meg fixen ott fog figyelni pár várakozó processz PER VIRTHOST. Ha mondjuk van 50 virthostod, alapbeállítással 250 processz fog elindulni php-ból.

A megoldás: virthostonként eltérő open_basedir! Annál is szépen meg lehet mondani, hogy melyik könyvtárakból indulva érhetnek csak el fájlokat.
3

Leves

janoszen · 2007. Jan. 27. (Szo), 10.46
Az MPM-perchild ment a levesbe. A megoldás a suPHP használata lett, méghozzá úgy, hogy minden domain-nek külön php.ini-je van. Ez azért szép finom, mert egyrészt az open_basedir működése nem feltétlenül mindig biztonságos (doksiban is le van írva: flawed concept) és ráadásul ha a PHP létrehoz egy fájlt apacs júzerként, akkor azt FTP alól már nem lehet módosítani, mert alapvetően nem szokás chmodolni ezeket.

Szóval a suPHP szép és jó, örülök magamnak, valamikor a napokban le fogok futtatni egy preformance tesztet, hogy mennyire gyors. Még a FastCGI-t nem próbáltam ki, lehet, hogy majd arra is sor kerül.

Ja, és aki próbálkozik: azért kell külön php.ini fájl, mert be kell állítani a doc_root-ot benne minden domainre, különben a "No input file specified" hibába ütközik a dolog.
4

Fastcgi

Hodicska Gergely · 2007. Jan. 29. (H), 04.12
Még a FastCGI-t nem próbáltam ki, lehet, hogy majd arra is sor kerül.
Elvileg már nagyon régen megírta Dénes ezt a cikket, de sajnos még nem jutottunk el oda, hogy kikerüljön hozzánk a végleges verzió, addig is a draft verizó: :)
http://donci.internode.hu/phpfastcgi/phpfastcgimodban.htm


Üdv,
Felhő
5

Koszonom!

janoszen · 2007. Jan. 29. (H), 09.02
Hoppa, asszem sikerult egy kicsit tagitani a horizontomat. Nagyon jo cikk, tetszik. Egy kicsit esetleg bovebben kifejtesre kerulhetne az, hogy hogyan is futtatunk egyedi php.ini-vel, mert az nem egeszen derul ki a cikkbol.

Egy hiba: Az egyik forraskodban van egy typo, a Directory elol hianyzik a nyito kacsacsor, meghozza itt:

<Location /fcgi/>
    SetHandler fastcgi-script
</Location>
Directory /home/foo/webroot/ >
    Options FollowSymLinks Indexes ExecCGI
6

pár virthost esetén még jó is lehet

js · 2007. Jan. 30. (K), 22.58
Ezzel az a gond, hogy ha már nem fér ki egy képernyőre a PHP-t használó virthostjaid listája, kissé pazarló. Másrészt én sehol sem találom a doksiban leírt "flawed concept"-et, azonban már hasonló kifejezést hallottam a safe_mode-ra. A Suhosin patch használata mindenesetre ajánlott.
7

Dede

janoszen · 2007. Jan. 31. (Sze), 13.00
Őőő a Debianhoz adott secutiry doc (/usr/share/doc/php5 talán) alatt benne van, hogy aki csak erre támaszkodik biztonság tekintetében, nem fog teljes supportot kapni.

Egyébként valszeg azért, mert a a nem-PHP-s dolgok vígan tesznek az open_basedir-re...
8

A debianosok azt mondanak, amit akarnak

js · 2007. Feb. 1. (Cs), 17.16
Most akkor pontosan mit is akarunk védeni? Ha PHP-t, akkor védjük a PHP-t. Ha mindent, akkor miért is engedünk meg CGI-t? Engedjük egyáltalán a PHP-t process-t spawnolni?

Egyébként minden tiszteletem a Debian security csapatáé, de mindezek ellenére azt kell mondanom, hogy széllel szemben nem lehet. Túl sok mindent csinálnak nagyon kevés eredménnyel.
9

Tény

janoszen · 2007. Feb. 1. (Cs), 18.27
Tény, hogy nagyon lassan dolgoznak egy-két témán, de azért veszem ezt az irányt, mert nekem sem tetszik, hogy a PHP igazgatja a saját biztonságát. Különben mod_php-vel mentem volna...