ugrás a tartalomhoz

Apache és CGI biztonságosan

Medvesajt · 2006. Jan. 12. (Cs), 20.44
Hali mkinek!

szeretném megoldani azt, hogy az Apache a cgi-s progikat a <VirtualHost>-ban megadott felhasználó és csoport szerint futassa. Próbálkoztam a suexec-kel. A manuál szerint fordítottam (Debian), tehát külön megadtam a configure-nak a suexec-es opciókat is. A helyzet az, hogy ezzel a verzsönnel bár fut az apache, nem szolgál ki egyetlne oldalt sem, aszondja, hogy nincs jog. Biztos, hogy a konfig-gal van a baj, de már a manuál szerint és más oldalak szeinr is próbálkoztam, ezek variációival, de nem akarja az isetnnek sem. létezik gondolom más megoldás is, pl a fastcgi, vagy cgiwrap.

Ki hogy oldja meg a cgi-k biztonságos futtatását, illetve milyen konfiggal?
 
1

Nem hiszem el!!

Medvesajt · 2006. Jan. 13. (P), 05.47
Alig bírom elhinni, hogy se itt, se a levlistán, sőt, még más fórumon és levlistákon se tud senki egy mondatot se írni a cgi-s programok futtatásáról. Ez nagyon elkeserítő :(
2

Türelem

aries · 2006. Jan. 13. (P), 10.55
Legyél egy kicsit türelmesebb, egy hét után érdemes bosszankodni.
--
Aries
http://aries.mindworks.hu
3

nem érdemes bosszankodni :)

Hojtsy Gábor · 2006. Jan. 13. (P), 11.53
Én nem mondanám, hogy érdemes bosszankodni. Kevesen használnak gyakorlatban CGI-s PHP-t, mert a modul olyan kényelmes (bár megosztott rendszeren nem olyan biztonságos).
4

Olyan vagyok, mint egy birka :)

Medvesajt · 2006. Jan. 13. (P), 17.47
Birka türelmem minden nehézségen képes átsegíteni, és nem bosszankodom, egyszerűen csak ülök tehetetlenül órák hosszat, és tudom hogy hiábavaló, de foglalkozom vele. Közben pedig megy az értékes gépidőm (illetve a programozásra fordítható időm), ez az ami elkeserítő a legjobban.

Annyi mindent megpróbáltam már, hogy az már eszméletlen. Felsorolom: először is, a manuál szerimt csináltam mindent. aztán a neten talált manuálok szerint csináltam mindent.Aztán megvettem az Apache kézikönyvet, és aszerint csináltam mindent. Aztán egy általam személyesen nem ismert, de nagyon segítőkész ismerősöm segítségét kértem (aki Cpanel-t használ), és úgy próbáltam, de ez nem ütött, mert szerintem a Cpanel írt magának egy security megoldást külön az Apache-hoz. Aztán megpróbáltam a különféle kombinációkat, de ezek is mind a suexec-re épültek.

A legnagyobb probléma, hogy mikor a suexec-kel fordítom az Apache-ot akkor hiába indul be, semmit nem engedd, még a saját docroot-ját sem. Szóval a sínemről már letértem, sehol nem mondanak semmit, és ez olyan elkeserítő. Már nem az érdekel, hogy megoldjam a problémám (mert ez az), hanem nem akarom, hogy valami kifogjon rajtam.

Nem is az a lényeg,hogy a php fusson cgi-ként (bár végül is az), hanem az, hogy akármelyik cgi-s progi az adott felhasználó jogaival fusson. Osztott rendszerem van, modulos php-val, de mert még nem kértek php-s futtatást, ezért nem is aggódtam. Viszont most merült fel igény,és most már gondolom kell jobban a biztonságra.
Lehet, hogy síkitanom kéne ?!
6

fastcgi

Hodicska Gergely · 2006. Jan. 16. (H), 09.12
Alig bírom elhinni, hogy se itt, se a levlistán, sőt, még más fórumon és levlistákon se tud senki egy mondatot se írni a cgi-s programok futtatásáról. Ez nagyon elkeserítő :(

PHP listán kaptál Dénestől egy tippet, amin átsiklottál a nagy kesergésben. ;)
http://www.trilithium.com/johan/2005/04/apache2-fastcgi/
Nem ismerem a témát, de hátha innen el tudsz indulni, plusz linux listán érdemes érdeklődnöd még.


Felhő
8

nekem nincs meg :(

Medvesajt · 2006. Jan. 17. (K), 21.26
Azért siklottam át nagy kesergésemben a levlistán, mert nem kaptam ilyen tippet. átnéztem vagy ezerszer is, és nincs olyan levelem. De azért köszi, hogy nekem ide szúrtad, mert egyből okosodtam a fastcgi-t illetően. Már azt is beállítottam, de egyenlőre nem használom, azt akarom, hogy legalább a suexec működjön.

De pl az okoskodók fórumán nem kaptam egyetlen választ sem :( oda sem megyek többet, amúgy is utálnak, mert nem használom a smartyt, és Linuxos vagyok :D
5

Egye meg aCGI-t az, aki főzte!

Medvesajt · 2006. Jan. 16. (H), 02.52
Hát az apache CGI-be való forgatása, az aztán macerás. Azon gondolkodom, hogy hagyom a fenébe, marad a modulos php. A felhasználók úgyis a rendszer felhasználói, tehát elméletileg két oldalról kéne megvédeni a szervert: a felhasználói oldalról, és a böngészői oldalról.

A felhasználói oldalról nem nehéz, a felhasználó és a csoportja ugyanaz, máshova nem is tartozik, egykén áll magában. A böngésző oldalról van gáz, mert az Apache-nak tudnia kéne olvasni a fájlokat, a könyvtárakba tudnia kell belépni. Ezt úgy érhetem el elméletileg, hogy az apache felhasználóját hozzárendelem az összes felhasználó csoportjához, tehát az apache nagyon sok csoport tagja lesz, de a felhasználó nem tagja az apache csoportjánaK.

A felhasználó csoportja kap olvasási és írási jogot, de az open_basedir-rel leszabályozom a kilépéseket (és safe_mod = ON).

Most már itt tartok, miután átvettem az apache 2.2, 2.0.x, és az 1.3 verzióit, a manuálok, netes anyagok útmutatását, használva a suexecet, a suphp-t és a fastcgi-t. Egyik sem működik, a legtöbb esetben maga az apache sem.

Azon gondolkozm, hogy más alternatíva felé nézek. valahol azt olvastam, hogy a jövő a kernelben lévő webszerverekké. hallottatok erről valamit?
7

Már majdnem megy :))

Medvesajt · 2006. Jan. 17. (K), 21.21
Úgy érzem, hogy be kell számoljak arról, hogy azért érnek sikerek is, ezért aztán nem leszek teljesen frusztrált :) Egyben újfent segítséget kell kérnem!

A helyzet az, hogy sikerült végre a suexec-et működésre bírnom. Hát, alig hittem a szememnek, mondanom se kell, hogy dobogott is a kis szívem rendesen :D

Azt már szinte el sem merem árulni, hogy az Apache kézikönyv illetve pár netes oldal és levelezőlista anyag alapján ollóztam össze végre a használható megoldást. Apache kézikönyvként a papírformátumra gondolok.

Hihetetlen, de telepítésként semmit nem kellett a configure-ban megadni, ami a suexec-kel kapcsolatos. Valszínűleg ezen hasaltam el ...
Bele kellett másznom a suexec forrásába és át kellett írnom pár dolgot, aztán lefordítani csak a suexec-et és bemásolni az apache-hoz (illetve oda, ahová megadjuk a forrásban).
ezzel még nincs vége, bele kellett másznom a httpd forrásába is, és abban is kellett eszközölnöm változásokat, aztán újrafordítani az apache httpd fájlját.
Akinek ez még nem elég, annak nyalánkságként elmesélem, hogy a httpd.conf-ba nem kell bele illeszteni az "AddModule mod_suexec.c" direktívát, mint ahogy az le volt írva pár oldalon.

És voila, mükszik! Az error.log-ban ott tipor a jelentés, hogy suexec enable, stb, stb, van suexec.log is végre.

Ezután értek az újabb kalandok? Ki gondolná, HOGY szeretett Firefoxom megfingat, de rendesen!!!!
A sztori: először tesztingeltem az apache statikus részét, és az jól működött. Aztán hozzáadtam egy virtuális hosztingert, és nem akart menni. csavarom, így csavarom úgy, és semmi, mindig az alapértelmezett documentroot-ban tiport a böngésző. Nézem a logokat: semmi. Újraindítom az Apache-ot: semmi. Már ezredszer éreztem azt, hogy az apache lesz az első, amit NEM teszek fel egyetlen gépemre se, mikor arra gondoltam, hogy talán nem is az apache a bűnös, és lám: Firefox bácsi akkor is kiszolgálta az oldalakat, mikor egyetlen webszerver sem ment.

Na, ekkor bújik elő Opera, konqueror, és egyből jó volt minden. ezután jött a php. Először is beállítottam, hogy menjen a documentroot-ban (cgi-s verzsön). Hát ment is. Ez aztán ment a Virtuális hosztingereknek is. egyből megtudták nyitni az /etc/passwd fájlt, ami annyira nagyon nem tetszett. A szakkönyv szerint VirtuálHoszton belül "SuexecUserGroup userneve csoportneve" direktívával lehetne szabályozni a dolgokat.

Azt hittétek?! Hát NEM!!!!!!
Egész egyszerűen "User userneve Group csoprotneve". Látjátok az ördögi csavarokat?!
Ez a lépés amúgy érthető, hiszen a suexec nem lett belefordítva az apache-ba, mert azt külön csináltam, a konfiguréban semmi nem szereplt, ami a suexec-re utalna. Így aztán a direktívát nem si lehet használni, mert nincs.

De amikor megadtam a User és Group direktívákat, azon nyomban bekrepált!!
Szóval Internal Server error. de volt már olyan is , hogy "No input file specifed" vagy mi. (nem vagyok nyelvoktató[se tanuló[se angol]])

Szóval van bőséges errorszöveg, de akinek ez nem elég, annak tudom tálalni a suexec.log-ból az alábbiakat:

"[2006-01-17 19:34:46]: info: (target/actual) uid: (proba.hu/proba.hu) gid: (proba.hu/proba.hu) cmd: php5-ujcgi
[2006-01-17 19:34:46]: error: command not in docroot (/usr/local/php5-ujcgi/bin/php5-ujcgi)"

Elismerem, ez mindennek a csúcsa!!

logikailag annyit kitudtam következtetni, hogy a suexec okozza a hibát és valószínűleg a suexec-ben szereplő docroot direktívával van összefüggésben. Először azt hittem, hogy a jogokkal van a gond, a fájlok és könyvtárak elérési jogaival, úgyhogy azzal focizgattam egy ideig, de aztán valahol az ezredik weboldalon olvastam erről, végikövettem a levlistán vagy 200 levélvátást, amiben a kérdező feltett egy kérdést, a válaszoló pedig válaszolt rá, de ez vagy két héten keresztül, és én pedig most velük - szóval abból kiszűrtem, hogy mi is lehet a gond. Viszont elfáradtam, meguntam, mára lecsukom a rólót.

De aki tudja, és nem sajnálta a fáradtságot, hogy elolvassa ömlengésemet, az írja már meg nekem, hogy a suexec-docroot beállítható-e úgy, hogy "/home/*/public_html" ?
Mert elméletileg az a baja a suexec-nek, hogy most ez a "/usr/local/apache/htdocs" tehát ott futni fog a VirtuálHost User és Group direktívájával. De nem próbáltam. Viszont ha ezt átváltoztatnám a /home-osra, akkor használhatok * karaktert, vagy pedig az összes virtuál fel kell sorolnom a suexec forrásában??????? Mert valahol még ezt is olvastam :((((

Köszönettel: egy mára megfáradt, de soha nem adja fel Medvesajt
pacsi!