Sziasztok!
Szeretnek olyat csinalni az egyik virtualgepemen, hogy chrootolom a phpt akar dinamikussan (pl abba a konyvtarba ahol van), vagy fixen (a virtualgep konyvtaraba). Ezenfelul szeretnem tiltan az exec()-et, esetleg hogy kinek a neveben fut azt is jo lenne allitani (peldaul a php tulajdonosanak a neveben).
Valaki csinalt mar ilyesmit? Nem nagyon talaltam megfelelo leirast, safe_modenal pedig irjak hogy ki fog kerulni a phpbol, de nem irjak hogy mi valtja ki. Lehet errol tudni valamit?
Elnezest ha esetleg mar foglalkozik ezzel forumtema, kerestem de nem talaltam naprakesz informaciot. Ha valaki megis rendelkezik ilyennel mar a linknek nagyon orulok. :) :)
PHP Version 5.3.3-7
Apache/2.2.16 (Debian)
libapache2-mod-php5el megy jelenleg, meg csak igy hasznaltam phpt, de annyit mar okosodtam hogy valahogy cgi modba kene futtatni a fenti manoverek egy reszehez.
Koszonettel: lazly
- 2267 megtekintés
Hozzászólások
Hogy érted, hogy "abba a könyvtárba, ahol fut"? Ezt a <virtualhost> apache paraméterben állíthatod:
php_admin_value open_basedir "/home/userdir"
- A hozzászóláshoz be kell jelentkezni
+1, valamint open restrictions, és ne használj safe_mode-ot, mert az evil (alap dolgok nem fognak menni, mint pl http redirect)
- A hozzászóláshoz be kell jelentkezni
Ez jelent bizonyos fajta korlátozást, de ezért ez nem chroot.
De jó dolog, hogy van ez a beállítás, nagyon hasznos és ha jól tudom ez nem fog kikerülni a php-ból.
- A hozzászóláshoz be kell jelentkezni
Az openbasedir bakfitty, azt egy halom modul függvényén keresztül ki tudod kerülni.
Amit ajánlanék közelebbi nézegetésre:
http://php-fpm.org/
http://php.net/manual/en/install.fpm.php
http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html
Ja, és nem cgi-s (modulos) üzemmódban természetesen esélyed sincs chrootolni a php-t, csak az egész apache-odat egyben.
- A hozzászóláshoz be kell jelentkezni
Koszonom, meg fogom nezni! :)
-------------------------------
"A gorog katolikus noknek 8 dioptria alatt nem kotelezo a bajusz!" avagy "Nozni csak muholddal lehet..." | http://lazly.hu
- A hozzászóláshoz be kell jelentkezni
openbsd
- A hozzászóláshoz be kell jelentkezni
Az mennyiben segit, igy onmagaban, minden egyeb nelkul?
--
|8]
- A hozzászóláshoz be kell jelentkezni
Ez engem is erdekelne. :)
-------------------------------
"A gorog katolikus noknek 8 dioptria alatt nem kotelezo a bajusz!" avagy "Nozni csak muholddal lehet..." | http://lazly.hu
- A hozzászóláshoz be kell jelentkezni
hat ha openbsd-re teszed akkor csak mert bsd nem fogják a kisautok megtörni!
- A hozzászóláshoz be kell jelentkezni
Persze, mert mukodni sem fog. ;)
--
|8]
- A hozzászóláshoz be kell jelentkezni
openbsdn alapbol chroot -ban fut az apache, imho ugyan ez a chroot legyen mar jo a php -nak is...
- A hozzászóláshoz be kell jelentkezni
Jo, hat ilyet barhol lehet csinalni, kb 3 perc, nem kell hozza openbsd. De nem ez volt a kerdes, hanem az, hogy a phpt hogyan chrootolod (apache nelkul).
Ha chrootolnek, akkor semmilyen korulmenyek kozott nem tennem a webszervert es a phpt egy chrootba, mert az kb olyan, mint halottnak a csok. Szep gesztus, de nagyon ritkan van barmilyen eredmenye.
--
|8]
- A hozzászóláshoz be kell jelentkezni
lehet, hogy félreértem, de a suphp nem jó neked?
- A hozzászóláshoz be kell jelentkezni
A dolog úgy működik, hogy a PHP-t elindítod standalone FastCGI daemonként. Ha van legalább 5.3.3-as PHP-d, akkor van PHP-FPM, ami nagy királyság. Ezt szépen fölkonfigurálod, majd a webszerveredet ráirányítod a standalone PHP által odarakott socketre, legyen az Unix vagy TCP.
Az egyetlen dolog, amit így vesztesz, az a .htaccess-ből konfigurálható php.ini opciók, de azok egyébként is az ördögtől valók. Ezen felül a webszervered ugye a chrooton kívül lesz, ergó az még problémás lehet, főleg, ha engedsz rewriteokat a .htaccessből. Végeredményben akkor leszel biztonságban, ha valami nagyon pici webszervert beraksz a chrootba és lehetőleg bekorlátozod, hogy merre nyitogathat portokat.
- A hozzászóláshoz be kell jelentkezni
Nem tudom, nekem a display_errors neha hianyzik a nem-modulos PHP eseteben, mint .htaccess-bol allithato php valtozo. Tudom, hogy van ini_set (ha van), de nem mindig szivesen ganyolok bele egy kesz alkalmazas (pl. drupal, wp) kodjaba ilyent.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Egyedi php.ini-t kell gyártani. A .htaccess tényleg nem játszik.
- A hozzászóláshoz be kell jelentkezni
A custom php.ini talan rosszabb, mint a htaccess, az utobbira ugyanis van egy csomo korlat, mit lehet onnet megtenni, az elobbinek a szerkesztesi jogat viszont nem szabad, hogy megkapja a user - ott ugyanis a hatar a csillagos eg. Marpedig en pont olyan megoldason gondolkodom, ami nem arra epul, hogy minden ficni-fecni beallitasert az user support request-et kuld. Azt a vegletet mar ismerem.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
-
- A hozzászóláshoz be kell jelentkezni
Miert ne szerkeszthetne? Chrootolt kornyezet, nem lat ki belole. Ha olyanja van, piszkalja csak a phpinit, nem?
- A hozzászóláshoz be kell jelentkezni
Mondjuk igaz... en akkor is felnek picit...
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Ha van mondjuk Perl a gépen, akkor úgyis tök mindegy. A PHP védelme (lásd: open_basedir) lukas, mint a svájci sajt, úgyhogy kéretik oprendszer szinten védekezni, különben csúnya meglepetések fognak érni.
- A hozzászóláshoz be kell jelentkezni