Apache + PHP: Vlastník souboru po uploadu

napiste si setuid root shell skript, ktery provede chown filename v parametru na pozadovaneho vlastnika (ocheckujte si ale, jestli vam do parametru nekdo nestrka /etc/shadow nebo podobne lahudky), zaridte, aby skript byl videt z vaseho PHP a execnete ho po uploadu. tohle je ale EXTREMNI PRASARNA^TM a mel byste (tj. pokud vam v tom nebrani napr. 9mm nebezpecne blizko spankove kosti, tak musite) uvazovat o jinem reseni. na co to presne potrebujete ? ;-)

Zdravím, díky za reakci :)
Chci se podělit o kapacitu svého 'serveru' s několika známými a potřebuju vyřešit to, aby si navzájem nemohli do souborů ve svých adresářích a zároveň to, abych jim mohl nastavit diskové kvóty - proto zvlášť uživatelské účty.
Napadlo mě, že pomocí safe_mode a open_basedir by vlastníkem jejich souborů možná mohl být stejný uživatel, jako pod kterým běží Apache. Ale co potom s těmi kvótami? Musely by fungovat na adresáře bez ohledu na uživatele a o takové možnosti bohužel nevím :/

Malý nápad - v Linuxu je i něco jako skupiny uživatelů, pokud se tito uživatelé zařadí do skupiny se serverem (Apache), mohlo by to pomoci. Taky by se dalo využít možností ACL, ale tenhle skvělej nástroj není v každé distribuci, dá se ale doplnit.

Nerozumím, jak by mohlo zařazení do skupiny pomoci. Vlastníkem souboru po uploadu stejně bude User i Group podle httpd.conf, takže to kvóty neřeší. ACL mi nic neříká, ale hned se na to jdu podívat :)

Ach jo, asi bych měl jít spát, píšu tady kraviny. To, co jsem napsal, je sice užitečný, ale je to asi na nic. Škoda, že se, zdá se, nedají uplatnit kvóty od více skupin na jednoho uživatele (to by problém řešilo), uplatní se (asi) jen ta, kterou má uživatel v /etc/passwd.

Ještě mě tak napadlo, že by se dal použít cron skript přeměňující vlastnictví nahraných souborů (to by mělo smysl, kdyby uživatelé k datům přistupovali i jinak - z příkazového řádku na serveru, přes FTP apod.), ale Apache (a jím spouštěné skripty) by omezeny nebyly...

Přistupují i přes FTP, ale v tom je nejmenší problém, protože to nastavuje každému vlastníka zvlášť a ještě k tomu správně :)

Sice nechci tvrdit, že bych se v tomto dobře vyznal, ale když jsem si hrál s příkazy typu chmod u+s něco, tak jsem zjistil, že má smysl je používat jen pro programy, ne pro skripty. Proč? Identita uživatele je dvojí - efektivní a, řekněme, obyčejná. Efektivní je rozhodující pro přístupová práva, ta se mění tím chmodem. Jenže když se spustí podproces (fork+execv), získá efektivní identitu podle té obyčené identity rodičovského procesu. Takže aby to fungovalo na 100%, je potřeba před spuštěním potomka udělat něco jako setuid(geteuid()), to ale může jen root. Aby byl skript spuštěn pod identitou jiného uživatele, je potřeba vložit nějaký prográmek, který nastaví obě identity na žádanou hodnotu. Ale jak je napsáno výše - je to HNUS. Udělal jsem to jen jednou, aby mi PHP skript na požádání spouštěl občerstvení dat pomocí SVN. Kupodivu to fungovalo, ale bylo to hnusný.

No, dozvěděl jsem se, že existuje třeba něco jako suphp (http://www.suphp.org), ale to mi přes veškerou snahu nefunguje. Tak si začínám myslet, že je to jen pro PHP běžící jako CGI.
Navíc i samotný safe_mode se řídí podle chownu. Ale už s ním nepracuje dál při vytváření souborů ...

Ano, suPHP, běží jen pro CGI.

Naivní pokus o radu:

nešlo by do adresářů, kam mají skripty zapisovat, dát suid bit na požadované usery?

Nebráním se žádnému rozumnému řešení, které povede k cíli. Nicméně u tohoto bych Vás poprosil o malinko bližší vysvětlení nebo nějaký zajímavý odkaz ...

Neradím, řešení, jen pokus

zkuste povolit živateli serveru zápis jen do jednoho vymezeného adresáře pro příslušný web. Tento adresář přivlastněte danému uživateli/skupině s hoďte na něj SUID/SGID bity. Při troše štěstí budou tvořené soubory pomocí move_uploaded_file a write a podobně mít nastaveného vlastníka na uživatele, co vlastní adresář

SGID nestaci a SUID nefunguje.

Odpoved na otazku Proc:
Jadro ignoruje prava nastavena pomoci chmod u+s u skriptu zacinajicich #!/bla/bla/bla
Pisou to v manualu, ale uplne nekde na konci...taky mi to trvalo:)

Co to udelat takto:
uzivatel uloadne soubor prez php (ktere si ho overi, zda je to on) a po ulozeni ho PRESUNE (mv) do adresare typu blabla/dowloady/uzivatel
Ten adresar je nastaven tak, ze tam muze psat a cist jak skupina Apache, tak dotycny uzivatel (jako uzivatel).
kazdy uzivatel ma v crontab naplanovany skript (rekneme na kazdych 5 minut), ktery probehne vsechny soubory v blabla/dowloady/uzivatel a pro kazdy z nich provede
cat blabla/dowloady/uzivatel/soubor>/home/uzivatel/dowload/soubor
rm blabla/dowloady/uzivatel/soubor

Ten skript bezi pod danym uzivatelem, takze jim VYTVORENY soubor bude jeho a v jeho kvote, v tom adresari blabla/dowloady/uzivatel smi cist i mazat, ale do cizich souboru se nedostane, neb ty patri apachovi a od blabla/dowloady/jinyuzivatel uz prava nema ;-)

Trochu oklika, ale melo by to fungovat ;-)

a co kdyz se nekdo trefi mezi crony ?

nehlede na to, ze cekat pet minut, nez se mi neco stane se souborem, ktery jsem nekam uploadnul (no dobre, v prumeru 2.5 min), budu fakt jenom jednou. pak ho uploadnu nekam jinam.

Dobré ráno, je vidět, že jste šel spát o chvilku dříve :) Já na to ještě moc nevidím ...
Jinak souhlas. Uvažoval jsem také o možnosti s cronem, klidně tak, že se každou minutu nastaví rekurzivně chown daným adresářům podle infa v db. Ale to si fakt myslím, že není řešení vhodné pro Linux (tedy stále v to doufám) ...

Moje reseni je lepsi v tom, ze se na kazdy soubor sahne pouze jednou a od te chvile uz ho ma uzivatel "doma" a system o nem nevi a nezdrzuje se s nim...
jinak mi to moje neprijde az tak moc "proti srsti", nepoterbju tam nikde spoustet nic s nadbytecnymi (rootovymi) pravy, proste se uzivatele mezi sebou dohodnou a kazdy se stara o sve.
Pokud zrovna chvili nikdo nic neuploadnul, tak ten skript zkontroluje ze je adresar prazdny a hned konci, pokud je nejaky novy soubor, tak se zkopiruje tam kam ma a tim je vystarano - uz ma spravne atributy a system s nim dal nic delat nemusi a ani nedela ... tak trochu jako stahovani posty.

A neni problem, pokud by nekdo spechal, si ten skript spustit i sam jako uzivatel a dostat ten soubor hned "mimo poradi" ;-)

Jenom opravdu nevím, jak byste PHP přinutil uploadovat tam, kam chcete Vy, a ne tam, kam chce uživatel. Ten použije v lepším případě move_uploaded_file() a očekává, že to bude hned fungovat ...

jakekoliv reseni bude vyzadovat spolupraci uzivatele.

uploadovaci stranka odesle formular nejakemu PHP. To popadne dosly soubor a prehodi ho do toho adresare blabla/dowload/uzivatel treba prave tou funkci move_uploaded_file() ... kdyz uz jsem u toho, o jak velke soubory a jake pocty se jedna? Je to cekani v prumeru pul minuty vaznou prekazkou?

jenze sam si ho prave nespusti. pokud se nebavime o tom, ze ma shell a spusti si ho ruco odtamtud.

V tom pripade pocka dokud se o to nekostara cron ...

To je v poradku, proste chvili pocka.
Pokud by to bylo poterba, tak se to da spoustet z cronu i kazdou minutu ....
Jde o to, na co se to bude pouzivat, zvlaste pokud tam maji uzivatele i FTP pristup.

A nesel by ten cron obejit tim ze bych do domovskeho adresare usera hodil suid skript (pouze prava uzivatele) kterej by si to zkopiroval z ty docasny slozky. Ten skript bych spoustel z php pri kazdym uploadu...

tak jsem chvili googlil, a obavam se, ze bez setuid skriptu (resp. teda binarky - #!/bla/bla/bla;) se neobejdete.

Dobrá, ale co teda s tím? Snažím se, ale nechápu :/
Průběžně děkuju za trpělivost ;)

no, uzivatel si pocka, az mu dobehne upload, pak na nej spusti binarku, ktera umi to, co ten shell-script popisovany vyse a pak si s vyslednym souborem dela co se mu zamane. tohle reseni ma tu vyhodu (nebo nevyhodu... ;), ze existuje pouze mala (casova) dira, kdy je soubor citelny pro vsechny. pro opravdu spravne a bezpecne reseni by IMHO bylo nutne napsat modul (apache nebo php), ktery soubor rovnou zalozi s prislusnymi vlastniky a opravnenimi. ja jsem asi deset minut googlil, a zadny nevygooglil - ale treba budete mit vetsi stesti.

Muj prispevek ukazuje ciste reseni bez jakehokoli setuid ;-)
(pravda, google ho nejspis jeste nema zaindexovany ;-)

no, kdyz jsem tohle zkousel jako reseni pro zakaznika, tak se mnou a s tou minutou pekne vybehl.

nehlede na to, ze do cisteho reseni to ma dost daleko (co ten race tam ?) ;-)

Ehm... jaky race?
pokud PHP po stazeni _presune_ ten soubor (v ramci jedne partition, takze se jen prepichnou pointery) tak ten soubor v meziadresari bud je, nebo neni. Kdyz tam je, lze z cronu zkopirovat a smazat.

Ledaze by byl tak velky, ze by ho ten cron nedokazal mezi dvema vyvolanima zkopirovat, ovsem to jsme asi v jine dimenzi, nez tam, kde se vycita, ze uzivatel musi v prumeru pul minuty cekat, nez se cron probudi ...

jde o to, ze je tam jista chvile, kdy ma soubor nebezpecneho vlastnika/prava, tudiz muze byt uzurpovan jinym uzivatelem.

Jak je napsáno výše, chmod g+s adresář způsobí, že v adresáři vytvořené soubory patří stejné skupině, jako ten adresář. (To jsem netušil, člověk se učí pořád ;-) Stačí tak každému uživateli zřídit další skupinu, té nastavit kvótu a nastavit tuto skupinu pro daný adresář včetně atributu setgid. ACL ani nebudou potřeba, stačí třeba něco takového:

groupadd franta_php
mkdir franta_php
chown httpd.franta_php franta_php
chmod 2770 franta_php
setquota -g franta_php soft_kb hard_kb soft_soubory hard_soubory /cesta

no, ale k temhle souborum opet muzou vsichni. (pres PHP, samozrejme).

Jo, můžou. Ale jak jsem se tak koukal po netu, našel jsem (nejen) toto:

php_admin_flag open_basedir /cesta

To se dá v httpd.conf nastavit pro každej adresář zvlášť, čímž by se obešla to, že tam jinak můžou všichni. (Snad...)

Myslím, že kombinace chmod g+s a open_basedir by mohla být ok.
Ale teď co s FTP? Konkrétně .. dokážu jej nastavit tak, aby správně nastavovalo vlastníka souborům. Ale pokud si někdo nastaví u adresáře přes FTP chmod (přes PHP jsem ještě netestoval), příznak zadaný dříve příkazem "chmod g+s" zmizí :/
(Ano, asi i tak nachystám něco pro cron, co bude nastavovat chown, ale stále to nepovažuju za řešení s velkým Ř)

Dalo by se zakázat použití příkazu chmod přes FTP. Hodilo by se nastavit jako výchozí vlastnost setgid, ale ACL to (asi) neumí. Možná rozšířené atributy nastavované pomocí (třeba) setfattr by to zařídily, ale to je nad rámec mých znalostí.

Jediné Správné Řešení^TM je Dopsat Ten Modul (perchild) ;-);-)

Začínám si myslet, že to snad vyzkouším.
Jak moc je ten modul nedopsaný? Jde 'jen' o potenciální chyby nebo nějaká část zcela chybí? V knížce Apache Server 2 - kompl. příručka administrátora to berou jako hotovou věc, i když okrajově :) Považujete za moc velké riziko se jej pokusit použít?

Začínám si myslet, že to snad vyzkouším.
Jak moc je ten modul nedopsaný? Jde 'jen' o potenciální chyby nebo nějaká část zcela chybí? V knížce Apache Server 2 - kompl. příručka administrátora to berou jako hotovou věc, i když okrajově :) Považujete za moc velké riziko se jej pokusit použít?

Omlouvám se za duplicitu a snad jen pro jistotu - vyzkouším modul, ne jeho dopsání :)

nejdriv bych to otestoval na laptopu, pak spustil zatezove testy (apache neco takoveho ma) a kdyby se to dostatecne dlouho nesesypalo, tak bych to nasadil naostro. totiz pokud ve vasem pripade nepripada v uvahu projet zdrojaky ;)

Tak jsem to překompiloval na perchild, vyžádalo si to také znovu kompilaci php. Weby běží, ale pokud k některému virtualhostu přidám následující řádek, pak daný virtualhost přestane reagovat:

AssignUserID uzivatel1 skupina2

Pro jistotu dodávám, že uzivatel1 i skupina2 existují a uzivatel1 je jejím členem. Také v http.conf mám

ChildPerUserID  uzivatel1 skupina2 1

a jeden proces běží pod tímto uživatelem (s čímž byly původně problémy, ale šlo o vyřešený bug - http://issues.apache.org/bugzilla/show_bug.cgi?id=7921), vypadá to takto:

uzivatel1 16209  0.0  1.2 89496 13044 ?       Sl   01:05   0:00 /usr/local/apache/bin/httpd -k start -DSSL

Samozřejmě mám možnost funkčnost se zátěží otestovat (nejsou to testy od apache, ty jsem zatím nenašel) a pokud to bude fungovat, budu spokojen. I když nevím, jaké budou časem nároky na RAM apod. Trochu mě ale mrzí, že neexistuje jiné řešení ...

zátěžové testy pro apache od apache: http://httpd.apache.org/test/flood/

Opravdu ti to funguje? Kolik mas na tom stroji virtualu ?
Kdyz jsme to zkousili naposledy, tak se zacal apache zasekavat uz pri
trech virtualech. Mozna to je ale tim ze jsme chteli aby se navic i chrootaval,
takze mu nemohli fungovat ty fcntl zamky.

Jeste posilam odkaz na dalsi web:
http://web.sysfrog.org/log/2004/05/apache2-perchild-mpm.html

apache to umi...
http://httpd.apache.org/docs-2.0/mod/perchild.html#assignuserid

ale jen pod virtualhostem. coz (afaik) neni zdejsi pripad.

Ok, a co si myslíte o tomto (na téže stránce nahoře)?

This module is not functional. Development of this module is not complete and is not currently active. Do not use perchild unless you are a programmer willing to help fix it.

Lze nasadit nebo ne?

are you a programmer willing to help fix it ? mozna byste tam mohl pridatt tu podporu useru v ne-virtual hostech ?

Nejsem :) koneckonců mně jde o virtualhosty. IP je jen jedna ...

nasadit to mozna pujde, ale nejdriv to _poradne_ otestujte. a mozna, ze se v tehle diskusi najde clovik, ktereho dany problem zajima a je "willing to help to fix". a mozna, kdyz vecer jeste nebudu mit ze vsech ++ a {} mzitky, tak to (mozna) budu i ja ;))

testoval jsem to asi den

po nejake dobe to zacalo vytuhavat, fakt to pouzitelny neni a to varovani v dokumentaci je tam pravem :)

Soubor bych uploadoval pomoci vestavenych FTP funkci v PHP. FTP vam vlastnika nastavuje spravne - mate po problemu. Resil jsem tak upload treba na pipni.cz kde maji se safe mode silene problemy.

jenze vy nepotrebujete z PHP scriptu neco nekam uploadnout. vy potrebujete osetrit HTTP upload ktery vam prichazi zvenku.

FTP funkce použiju já, vy a pár lidí, kteří do toho malinko vidí. Ti ostatní použijí nějaký hotový skript. A kdo do toho uvidí hodně, mohl by právě nepoužitím ftp funkcí obejít kvótu :)

Aaaha uz jsem to pochopil, myslel jsem ze se snazite o neco trochu jineho(mit vlastni PHP script, pomoci kterehoi date userum sanci na upload jejich souboru na ssrver). Tak s timhle Vam drzim palce, ale poradit nedokazu:)

Spravne, najefektivnejsie a najprijatelnejsie riesenie zo vsetkych je predsa len upload via FTP na webserver - v principe je to len movnutie suboru via ftp na nejake konkretne miesto na webe - tym sa nastavi aj vlastnik suboru. Ftp server je nastaveny aby chroot-om prezentoval len urcitu cast webu, a dovolil sa prihlasovat uzivatelom len z localhostu.

no, sudo je stejny race jako suid binarka - i kdyz pripoustim, ze se nemusi nic psat. suexec funguje pro CGI, ne pro mod_php, je tak ?

Apache pobezi pod User=apache, Group=apache

rekneme ze GID apache = 33 a UID apache je take 33

uzivatele budou pak mit uid napr.
franta: UID=1000 (franta), GID=33 (apache)
blazej: UID=1001 (blazej), GID=33 (apache)

v PHP skriptu se pri uploadu nastavi umask() tak aby pravo na praci (cist/psat) mel nejenom uzivatel ale i skupina (tedy napriklad 117 pro soubory, 007 pro adresare)

uzivatele ve svych home zamknete pres open_basedir v PHP, na FTP pres chroot (vetsina ftp umi uzamknout uzivatele v home, doporucuji proftpd nebo pure-ftpd)

tim jsou vyresena prava, uzivatele nesmi mit pristup pres SSH a nesmi mit povolene CGI skripty a server-side includes (pres to by se dalo uzamknuti obejit)

co se quot tyce, tam je potreba udelat skript ktery nastavi spravne vlastnika na vsech souborech v uzivatelove home - jinak by se totiz soubory uploadnute pres web nezapocitaly do quoty uzivatele (patrily by UID=33 (apache)) - osobne mam ale s quotami tu zkusenost ze akorat komplikuji zivot, lepsi je jednou za cas rucne prepocitat kolik u jednotlivych uzivatelu zabiraji jejich data a zkontrolovat proti nejake tabulce, v pripade vyrazneho prekroceni je na to upozornit a domluvit se s nimi - protoze vetsina dat bude samozrejme warez tak warez nemilosrdne mazat :)

jeste lepsi je pouzit jedno UID i GID pro vsechny uzivatele, ale tam se quoty nedaji nasadit ani kdybyste chteli (sice pure-ftpd quoty umi tak, ze prepocita velikost souboru u uzivatele (i virtualniho) - ale nemam zkusenost a rekl bych ze to bude dost pomale)


hope it was helpful :)

co se quot tyce, tam je potreba udelat skript ktery nastavi spravne vlastnika na vsech souborech v uzivatelove home

Sem s ním! Nebo že by byl pro cron? ;-)

ano, pro cron :)

Jedine reseni, jak toto resit, je spoustet PHP jako CGI script pres SUEXEC. Pokud byste chtel tomu dat trochu vic vykonu, tak je zapotrebi to cele nakonfigurovat jako FastCGI.

Navod v nemcine:
http://www.debianhowto.de/howto-archiv/de/apache2-phpfcgi-sarge/

S pomoci tohoto a google translatoru to snad zvladnete. Neni to nic sloziteho a opravdu to funguje.

O.

Jedine reseni, jak toto resit, je spoustet PHP jako CGI script pres SUEXEC. Pokud byste chtel tomu dat trochu vic vykonu, tak je zapotrebi to cele nakonfigurovat jako FastCGI.

Navod v nemcine:
http://www.debianhowto.de/howto-archiv/de/apache2-phpfcgi-sarge/

S pomoci tohoto a google translatoru to snad zvladnete. Neni to nic sloziteho a opravdu to funguje.

O.

Jedine reseni, jak toto resit, je spoustet PHP jako CGI script pres SUEXEC. Pokud byste chtel tomu dat trochu vic vykonu, tak je zapotrebi to cele nakonfigurovat jako FastCGI.

Navod v nemcine:
http://www.debianhowto.de/howto-archiv/de/apache2-phpfcgi-sarge/

S pomoci tohoto a google translatoru to snad zvladnete. Neni to nic sloziteho a opravdu to funguje.

O.

Ten problem s vlastnikem po uploadu preci musi mit vic lidi, to opravdu neni nejake ciste reseni, neco jako direktiva do apache
treba "PHPFileUploadOwner jmeno" ktera by po uploadu zajistila
zmenu vlastnika ? Skoda.

Na serveru mi bezi dokonce PHP4 a PHP5 zaroven, to cele pres suphp. Tady je postup:
http://svn.gnqs.org/projects/gentoo-php-overlay/file/docs/php4-php5-configuration.html?format=raw

Resim ale ted problem s CGI - mam instly suexec, ale tam jde nastavit vzdy jen jeden uzivatel, pod kterym se CGI pousti...
A ja potrebuji poustet to pod vlastnikem toho skriptu, uctu je u nas pres dve ste...

SuexecUserGroup -user- -group-
-> co tam doplnit, pripadne cim to nahradit, aby to jelo? diky