Registrace nového uživatele     Návod     Kluby     Archív  Lopuchu     Lopuch.cz  

Komu se nelení,
tomu se zelení.

Lopuch.cz

Jméno:
Heslo:
Podpora LCD:
 
Klub Hosting [ŽP: neomezená] (kategorie Internet) moderují Jana, knedle.
Archiv
Domovská stránka aktualizována 28.7.2019 17:46
Chcete umístit někam svoje stránky. Stačí vám freehosting, nebo máte zájem o webhosting za peníze? V tomto klubu si můžeme vyměnit zkušenosti s obojím.

Hostingy www.jakpsatweb.cz/hosting.html Yuhů sepsal článek na téma "Co byste měli vědět o komerčním hostingu, než si nějaký objednáte."
  www.hormart.cz. Vyhledávač placených hostingů v České republice - možnost výběru i podle různých kritérií.
  www.hostingy.cz. Přehled a srovnání hostingů jednotlivých providerů. Seznam programů s možností vyhledávání.
Freehostingy - zahraniční www.freewebspace.net. Vyhledávač zde.
Freehostingy - domácí Články na www.grafika.cz - 1, 2, 3, 4.
  free.hostingy.cz
  freeweby.iglu.cz
Freehostingy - domácí s PHP a MySQL Na mých stránkách - zde.


Klub o webhostingu existuje i na Okounovi.
  Nastavení klubu     Nastavení práv     Homepage     Anketa     Přítomní     Oblíbené     Lopuch     Kategorie  
autor: 
text: 
vyplnit a 
Help
 Titulek, text příspěvku  
Opište pozpátku následující text bez prostředního znaku: tytieen
[ 161 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
themajkl themajkl All those moments will be lost in time - like tears in rain. 26.2.2007 09:16  695
Bredy [693]: Nedělám PHP. Ale zjistit práva a pak jen potřebná přidat, ne natvrdo nastavit nějaké numero.
Jinak podle toho výpisu je zřejmé, že to veškeré zabezpečení je založeno jen na tom, že tam druhého uživatele nepustí apache...
bredy 26.2.2007 09:14  694
dodatek: hosting jinak.cz
bredy 26.2.2007 09:13  693
Takhle vypadají práva v adresáři vyrobeném skriptem a do něhož zapisuju taky skriptem
drwxr-xr-x    2 65534    65534        4096 Feb 21 21:39 .
drwxrwxrwx   52 bredy    65534        4096 Oct  7 23:20 ..
-rwxrwxrwx    1 65534    65534     6452227 Feb 21 21:39 BytMnisek.zip
-rwxrwxrwx    1 65534    65534       43945 Aug 21  2006 HaskovaLipnice-060820_132821.jpg
-rwxrwxrwx    1 65534    65534       43942 Nov 30 22:17 Tom????ek8.zip-IMG_1340.JPG
-rwxrwxrwx    1 65534    65534       39958 Jun  9  2006 endy-050615_083053.jpg
-rwxrwxrwx    1 65534    65534       40280 May 10  2006 tomasek-IMG_0575.JPG
-rwxrwxrwx    1 65534    65534       80654 Jun 10  2006 tomasek-martina-igor.zip-IMG_0686-01.jpg
-rwxrwxrwx    1 65534    65534       82196 Jun 10  2006 tomasek-martina-igor.zip-IMG_0708-01.jpg
-rwxrwxrwx    1 65534    65534       43804 Aug 18  2006 tomasek4mesic.zip-IMG_1027.JPG


themajkl: A teď jak to napsat příkazem chmod v PHP
bredy 26.2.2007 09:11  692
tvxJá se domnívám, že tohle pravidlo platí s výjimkou souboru, které vlastní samotný apache. Totiž jinými slovy, můj skript může přistupovat k souborům, mající stejné UID jako skript, nebo mají UID webserveru. Samozřejmě že by to znamenalo, že skriptem jsi schopen přistoupit do složek a souborů jiných hostingů, které tyto soubory vytvořili skriptem. Nemám to ověřený.
themajkl themajkl All those moments will be lost in time - like tears in rain. 26.2.2007 09:09  691
Bredy [690]: chmod ugo+rwx
bredy 26.2.2007 09:02  690
fisMezi vývojáře, kteří po vytvoření adresáře nebo souboru udělají chmod (777) (nebo 666), se počítám i já. Na všech serverech, na kterých jsem své skripty honil téměř vždy byly soubory vytvořené skriptem nepřístupné z FTP a naopak (soubory nahrané FTP bylo sice možné číst, ale měnit už ne). Vždy pomohlo nastavení práv adresáře i souborů na 777 resp. 666. A fungovalo to i u zakládaných adresářů skriptem.

Netuším tedy, jak se to má dělat jinak, aby to fungovalo všude. Neznám pozadí implementace.
fis fis 25.2.2007 19:00  689
Problem je totiz v tom, ze zadne obecne a dostatecne uspokojive reseni proste s klasickym modelem apache + mod_php neexistuje a ani existovat nemuze.

Apache bezi pod nejakym svym uzivatelem. Pokud by to byl root, pak by sice mohl fungovat treba nejaky takovy patch, ktery zminuje tvx, ale bezpecnostni dusledky behani apache pod rootem jsou natolik ohromne, ze se vubec nedivim, ze si to nikdo neriskne (nejde ani tak o apache samotneho, jako spis o nektere externi veci typu PHP ci OpenSSL, ktera nemaji vubec dobrou bezpecnostni historii ani soucasnost). Dalo by se samozrejme toho roota orezat natolik, aby mel co nejmensi prava (pomoci ruznych systemovych ACL nebo capabilities), ale nevim o tom, ze by si nejaky hosting veril natolik, aby tohle implementoval.

Takze tedy nemame apache pod rootem a nejaky patch co upravuje prava dodatecne je mimo hru. Asi by se dal udelat nejaky externi proces pod rootem, ktery by na zadost apache jenom menil prava uzivatelu, ale... i to je asi pomerne snadno zneuzitelne. Uzivatel si sam zmenit vlastnictvi skriptu nemuze. Je zde tedy moznost mit skripty vlastnene primo uzivatelem, pod kterym bezi webserver. UID novych souboru a adresaru se bude rovnat tomu UID, ktery ma skript. To je super, jenze... to jaksi uz nema cenu provozovat safe_mode vubec, kdyz udelame tohle (vsechno bude mit jednoho vlastnika).

Pokud se nepletu, tak pokud mame adresar vlastneny vlastnikem skriptu, a soubory v nem jsou vlastneny apachem, neni problem pri zapnutem safe_mode se soubory v takovem adresari manipulovat, davat tam jine etc. Tudiz pokud si adresare predem pripravime, uploady to nezkazi, manipulace to nezkazi. Zkazi to mkdir, ktery vytvori adresar vlastneny apachem a v tom uz neudelame ani tuk. Proto nektere lepsi webove aplikace umi vytvaret adresare primo pres ftp.

Existuje jeden zpusob, jak se to da resit. Zapne se safe_mode nikoli podle uidu, ale podle gidu. A gid se da dedit. Lze zajistit, aby se gid podedil od otcovskeho adresare. Tudiz pak apache muze vesele vytvaret veci pod sebou, vytvorene adresare zdedi gid od sveho adresare rodicovskeho, soubory taky a php porovnava gid a vsechno funguje presne jak ma i se zapnutym safemode. Jenze... je to too good to be true. Na svete existuje asi tak miliarda PHP vyvojaru, co si mysli, ze vsechny webservery jsou nakonfigurovane stejne, a prvni co udelaji jakmile vytvori soubor nebo adresar, je to, ze tam vesele naperou chmod(777), cimz zrusi priznak dedicnosti GID a je po srande, metoda opet selhava.

Problem safe_mode i open_basedir (ktera asi jako jedina casem zustane) je jeste jiny. Vse je to vynucovane pouze v PHP a vzhledem k tomu, kolik funkci a rozsireni v PHP je, se nejde tak stoprocentne spolehnout na to, ze skutecne vsechny toto budou respektovat a kazdou chvili se prave najde chyba typu obejiti open_basedir nebo obejiti safe_mode... Je lepsi mit asi zapnute obe dve a doufat.

Mozna o neco lepsi je nepouzivat mod_php, ale mod_fcgid s fastcgi verzi PHP. To se ale velmi obtizne (az nerealisticky obtizne) udrzuje pri vetsim mnozstvim virtualhostu, chova se to obcas trochu divne. Ale vyhoda je jasna - muze to bezet primo pod uzivatelem vlastnicim dane skripty, tudiz je to bezpecnostne uplne jinde, nez safe_mode ci open_basedir (bezpecnost zde vynucuje system) a problemy se safe_mode odpadaji.
tvx tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 25.2.2007 12:17  688
PHP navíc obsahuje kontrolu, že v safemode nedovolí přistupovat k souborům, které nemají stejného vlastníka jako skript, který k souboru přistupuje
takhle je to správně! tedy, php nepovolí shat na soubory vlastněné ani apachem jak pises nesprane ty a v TOM je ten problem... existuje prej patch, kdy php vyrabi soubory pod vlastnikem spusteneho skriptu coz by byla sparvan cesta ale malokterej hosting tenhle patch pouziva,nebo spis u nas asi nikdo...
chown viz. KKL
kdokoliv Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 24.2.2007 03:08  686
Bredy [683]: Nevím, proč by chown neměl fungovat. Svůj soubor dávám někomu jinému, to snad může udělat jakýkoliv user, včetně usera Apache. Hehe, vtipalku. Tak si predstav, ze si nekde ve svym $HOME vytvorim soubor, pomoci prav v ceste k nemu zaridim, ze se k nemu nemuze dostat uzivatel bredy, a pak soubor predam uzivateli bredy. Ten mi jiste ohromne podekuje, jelikoz mu takhle krasne budu cerpat uzivatelskou quotu na velikost jeho souboru, zatimco svoji si budu setrit.
A s tim safe modem to bude taky slozitejsi, ja si s tim bohuzel moc nehral, ale na ty obtize s kombinaci souboru, ktere clovek vytvori z PHP, s temi, ktere nahraje pres FTP, jsem uz narazil v diskusich milionkrat a nejake obecne a dostatecne uspokojive reseni nikde a moc bych za to nedal, kdyby to bylo duvodem, proc je (pokud vim) safe mode zastaraly, upousti se od nej a ma ho nahradit neco jineho.
huh huh 24.2.2007 02:55  685
IIRC je dulezity pred jakoukoli jinou cinnosti se souborem pouzit move_uploaded_file. Ted jsem to zkousel na pipni a upload mi tam chodi naprosto bez problemu, clovek musi mit akorat nastaveno pravo na zapis pro vsechny do adresare, kam je uklada.
bredy 24.2.2007 01:10  684
ještě jednou a lépe. Vlastníkem webserveru je user apache. Skripty které spouští PHP jsou taky v kontextu vlastníka apache. Soubory, které skript vytvoří take mají vlastníka apache. Z PHP lze přistupovat ke všem souborům, jenž mají vlastníka apache.

PHP navíc obsahuje kontrolu, že v safemode nedovolí přistupovat k souborům, které nevlastní apache a nemají stejného vlastníka jako skript, který k souboru přistupuje.
bredy 24.2.2007 01:06  683
tvxjakmile skript vyrobí soubor, je vlastníkem apache. Skript běžící pod apachem může samozřejmě také změnit přístupová práva (chmod), tak aby tam měli přístup i ostatní (já tam rvu 0666 a neřeším to).

Nevím, proč by chown neměl fungovat. Svůj soubor dávám někomu jinému, to snad může udělat jakýkoliv user, včetně usera Apache.

Jinak pozor na vlastnictví. Všechny skripty běží pod userem Apache. PHP v safemode pouze kontroluje otevírané soubory a nedovolí otevřít soubor který patří jinýmu vlastníkovi, než je vlastník skriptu, který soubor otevírá. Tohle je vlastnost safe mode, a mám pocit, že se do tohoto pravidla nezapočítává vlastník webserveru (pod nímž vznikají nové soubory) a že se na chmod a chown nevztahuje (protože chmod a chown lze skutečně jen pustit na soubory vytvořené apachem)
tvx tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 23.2.2007 11:14  682
Bredyale ja jakmile vyrobim soubor, uz si na nej timto nesahnu! prava se neberou v uvahu, pouze VLASTNIK! a ten musi byt shodny s vlastnikem beziciho skriptu, zatimco vlastnikem je apache co to vyrobil. uz je jasno? chown muze pouze root nikoli apache...
bredy 23.2.2007 09:53  681
tvxhttp://cz.php.net/chown
http://cz.php.net/chmod

jen je potřeba při návrhu skriptu myslet na to, že když skript vyrobí soubor, tak je jeho vlastníkem.
tvx tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 17.2.2007 19:35  680
knedleupload je ejste v pohode,problemjepak dalsi spravovani,treba na pipni kdyz vyrobim soubor, je vlastnikem vzdy apac... avsak pote system vyzaduje k jeho manipulaci abych ten souborvlastnil ja, jedina moznost pripojovatse pro manipulace pres ftp z php...

[ 161 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  

(c) 2001-2011 Lopuch.cz   
Kontakt