Přihlášení

registrace ~ obnova hesla

MyEgo.cz › Jak funguje mkdir / chmod v PHP .

Jak funguje mkdir / chmod v PHP

Wednesday, 24.01.07 - PHP - autor: Radek Hulán

Řešil jsem dnes problém na ŠTĚRBA-KOLA.cz, kdy klient mohl nahrát soubory na web pomocí WYSIWYG editoru / PHP, nicméně dále je nemohl smazat přes FTP. Nechápal jsem proč, adresáře se vytvářejí pomocí mkdir($dir,0777), na soubory se nastavuje chmod($fp,0777), a žádná jiná prezentace s tím neměla dosud problém.

Vyřešilo se to až ve spolupráci s webhostingem (tojeono.cz). Problém je, že mkdir 0777 ve skutečnosti nedělá v PHP mkdir 0777. Bere totiž do úvahy i systémovou masku, která je typicky nastavená pro *nixové uživatele na 0022, takže udělá pouhé 0755. A v php.ini ani v httpd.conf se to bohužel nedá změnit. Pokud tuto triviální informaci víte, vše je jasné, já jsem ji do dnešního dne nevěděl. Je tedy nutné před mkdir() použít ještě umask(0000), tedy vynulovat masku, a vše bude fungovat dle očekávání.

Druhou možností je samozřejmě nastavit defaultní umask v *nixovém systému na 0000. Poté i PHP bude fungovat tak, jak očekáváte, a nebude problém v syncu práv mezi PHP a FTP. Je to nakonec nejlepší řešení, protože spousta skriptů umask nepoužívá, a dopisovat to do skriptů je poněkud méně pohodlné. Navíc umask funguje jen pro nejbližší další příkaz, poté se opět resetuje do původního stavu, takže se nedá vložit jen do nějakého config.php.

Bezvadné by bylo, kdyby PHP podporovalo v php.ini cosi jako set_default_umask, pár requestů na to již (pár let) je.

Wednesday, 24.01.07 - PHP - autor: Radek Hulán - 16793x

Komentáře:

  1. [1] martinm 132.236.broadband2.iol.cz

    S tímhle (0755) jsem se párkrát setkal, a neznaje fígl s umask() jsem se PHPčkem připojoval přes FTP a takto vytvářel adresáře a nahrával soubory. Děkuji za radu ;-)

    odpověz na tento komentář
    1. na komentář reagoval Radek Hulán — #2
    karma: 6 Wednesday, 24.01.07, 20:08:38
  2. [2] Radek Hulán

    odpovídá na martinm — #1 njn, ona je to úplně triviální věc, nicméně, těch trivialit je tolik, že není problém jednu minout..

    odpověz na tento komentář karma: 13 Wednesday, 24.01.07, 20:14:44
  3. [3] Michal Zimmermann 100-22.net.optinet.cz

    Sláva, konečně už nebudu muset otravovat podporu, ať mi vytvoří adresář s chmodem 777. Kolikrát jsem málem hodil monitor z okna, když se opět objevila hláška "cannot access /adresar in xy.php on line 5" nebo jak ta hláška vypadá.

    Vypadá to, že podpora tojeono.cz má kvalitu :o).

    odpověz na tento komentář karma: -1 Wednesday, 24.01.07, 21:59:35
  4. [4] Black Wolf ip-85-160-163-82.eurotel.cz

    Tohle jsme taky nějaký čas zpátky řešil, ale stačilo se podívat do manuálu PHP a projít komentáře k mkdir, tam to je. Manuál je občas k nezaplacení, obzvlášť vzhledem k tomu kolik má PHP funkcí.

    odpověz na tento komentář karma: 26 Wednesday, 24.01.07, 22:08:40
  5. [5] Dr. Zoidberg 201.6.broadband.iol.cz

    komentář byl vyhodnocen čtenáři jako brak

    odpověz na tento komentář
    1. na komentář reagoval Jakub Brabec — #6
    karma: -10 Wednesday, 24.01.07, 22:34:50
  6. [6] Jakub Brabec gw006154.nsys.cz

    [5] No jak to vezmeš - většina hostingů ma omezenou velikost databáze. Ukládat proto do ní soubory v binární podobě není nejschůdnější cestou.
    Jde pomocí copy kopírovat soubory do vzdálených adresářů jiných webu nebo ne?

    odpověz na tento komentář
    1. na komentář reagoval juneau — #7
    karma: 0 Wednesday, 24.01.07, 23:16:16
  7. [7] juneau kxklum08.knet.vse.cz

    odpovídá na Jakub Brabec — #6 Taky by mě zajímalo, jakou neplechu může 0777 na souborech/složkách způsobit.

    odpověz na tento komentář
    1. na komentář reagoval Jakub Brabec — #8
    karma: 0 Wednesday, 24.01.07, 23:26:55
  8. [8] Jakub Brabec gw006154.nsys.cz

    odpovídá na juneau — #7 Tak jsem si četl manuál a funkce copy neumí kopírovat přes http protokol. Myslím si, že práva 777 jsou adresáři bezpečná (některé servery mají nastavení tak, že 777 vypisuje zároveň obsah adresáře - to lze vyřešit umístěním indexu nebo zakázat indexes v .htaccess) a nevidím důvod nahrávat data do databáze. Dovolil bych si i tvrdit že data tahaná z MySQL binární podobou je pro webovou aplikaci opravdu blbost - musíte si nejdřív soubor binárně otevřít, pak uložit, pak stáhnout a poslat skriptu správnou hlavičku aby to jen nevypsalo sta řádků nesmyslů.

    odpověz na tento komentář karma: -1 Wednesday, 24.01.07, 23:46:48
  9. [9] Radek Strnad random.kolej.mff.cuni.cz

    A není tento problém uměle vyvolán špatnou konfigurací providera? Přeci každý FTP server při přihlášení přidělí uživateli práva. Proč prostě nemůže přidělit uživatele, pod kterým přistupuje PHP?

    odpověz na tento komentář
    1. na komentář reagoval Radek Hulán — #10
    2. na komentář reagoval Láďa — #11
    karma: 0 Thursday, 25.01.07, 00:29:33
  10. [10] Radek Hulán

    odpovídá na Radek Strnad — #9 provozovat FTP pod stejným uživatelem v Linuxu jako PHP je bezpečnostní sebevražda..

    odpověz na tento komentář karma: 11 Thursday, 25.01.07, 00:31:14
  11. [11] Láďa r5cw78.net.upc.cz

    odpovídá na Radek Strnad — #9 Třeba kvůli tomu, že potom ztrácí smysl safe_mode, na kterém je bezpečnost většiny obyčejných hostingů postavena? :-)

    Ale hlavně ať si to nepřečte nějaký "taky administrátor" a nenastaví umask na 0000 pro všechny včetně roota.

    odpověz na tento komentář karma: 4 Thursday, 25.01.07, 01:22:16
  12. [12] D1ce 83.74.broadband5.iol.cz

    Včera jsem řešil to samé, ale ani umask() nepomáhal, práva se podařilo nastavit jedině a pouze přes k tomu oprávněného ftp uživatele. Pokud by ani tohle nevyšlo, tak když by php bylo zkompilováno/instalováno s podporou ftp, šel by určitě kód přepsat používajíc ftp rozšíření k práci se soubory.

    ... kdy klient mohl nahrát soubory na web pomocí WYSIWYG editoru / PHP, nicméně dále je nemohl smazat přes FTP. ...
    Nějak mi uniká jak jsi vlastně zabránil tomu smazaní přes ftp.
    Jinak prosím omluv mé, určitě v poměru s tvým, nízké IQ, snad se ti mě zželí a relavantně odpovíš, protože já jsem se toho z článku nedovtípil a to jsem ho zpracovával cyklem while(1) než jsem přestal samým vyčerpáním. I když možná tuším, že tvé php nastavuje něco jako php user group, ke kterým pak nemá přístup určitá skupina uživatelů ftp. Opravdu nevím, děkuji převelice za případné vysvětlení. Omlouvám se také za případné stylistické a pravopisné chyby příspěvku, ale četl jsem to po sobě 5x, tak doufám, že to zas až taková hrůza nebude.

    odpověz na tento komentář
    1. na komentář reagoval llook — #14
    2. na komentář reagoval Hornster — #17
    karma: 7 Thursday, 25.01.07, 02:39:55
  13. [13] hojoFojo lysafreenet.cust.sloane.cz

    No jak se to vezme. Zalezi na hostingu kde si a jak ma v php nastavbnou promenou OPEN_BASEDIR(zjistis pomoci php info) Na jednom malem hostingu jsem zjistil ze to tam tak maji a pak si jednoduchym scriptem kdokoliv od tebe stahne celej web i se zdrojakama. Ale rekl sem jim o tom a oni to uz odstranili. Kolik dalsich hostingu je deravych, tak to tezko rict.

    odpověz na tento komentář karma: 3 Thursday, 25.01.07, 07:30:32
  14. [14] llook 22-118-207-85.strcechy.adsl-llu.static.bluetone.cz

    odpovídá na D1ce — #12 Řekl bych, že došlo k nedorozumění - citovaná věta nepopisovala zadání, ale nežádoucí stav. Je fakt, že slovo "problém" se často používá pro obojí.

    Cílem bylo, aby to šlo mazat přes FTP, jenže to nešlo, protože PHP nevytvořilo anarchistický soubor (kdokoli smí cokoli), ale soubor s právy rwxr-xr-x.

    odpověz na tento komentář
    1. na komentář reagoval D1ce — #22
    karma: 0 Thursday, 25.01.07, 09:00:05
  15. [15] vlk 194.213.43.206

    to je ale priklad pomerne laxne napsane aplikace, resp ne-snaha nakonfigurovat to spravne a "pohrat si s tim" ... pristupova prava jsou tam proto, aby se pouzivala .. tzn, veskera webova prezentace ma mit prava 700 resp 600 pouze pro uzivatele pod kterym bezi HTTP daemon, nikdo jiny k nim nema mit pristup .. pokud je potreba, aby uzivatele neco na server uploadovali nebo mazali jinak pres HTTP daemon, je potreba prislusne nakonfigurovat pro ty ktere adresare ty sluzby a skupiny ktere s nimi maji pracovat, tedy v nejhorsim 770/660 ... nastavit na cely web vcetne uploadnutych souboru 777 je proste absolutni zhuverilost

    odpověz na tento komentář karma: 1 Thursday, 25.01.07, 10:10:19
  16. [16] Maťko server.bryans.sk

    Možno som trochu mimo, ale ja som zatial používal unlink () na mazanie suborov. Na dvoch rôznych hostingoch a zatiaľ nebol problém.

    odpověz na tento komentář karma: -8 Thursday, 25.01.07, 10:47:19
  17. [17] Hornster mail.spsostrov.cz

    odpovídá na D1ce — #12 Všimni si v té větě rozdílu mezi slůvkem, kdyby bylo slůvko kdy nahrazeno za aby.

    odpověz na tento komentář
    1. na komentář reagoval D1ce — #22
    karma: -2 Thursday, 25.01.07, 11:09:55
  18. [18] --==[FReeZ]==-- ip-89-102-167-110.karneval.cz

    komentář byl vyhodnocen čtenáři jako brak

    odpověz na tento komentář
    1. na komentář reagoval Black Wolf — #19
    2. na komentář reagoval Láďa — #20
    karma: -10 Thursday, 25.01.07, 11:52:24
  19. [19] Black Wolf ip-85-160-165-184.eurotel.cz

    [18] Právě naopak, ty nuly tam jsou zcela správně, naopak bez nich by to bylo špatně, viz. manuál PHP - "To ensure the expected operation, you need to prefix mode with a zero (0):
    <?php
    chmod("/somedir/somefile", 755); // decimal; probably incorrect
    chmod("/somedir/somefile", "u+rwx,go+rx"); // string; incorrect
    chmod("/somedir/somefile", 0755); // octal; correct value of mode
    ?> "

    odpověz na tento komentář
    1. na komentář reagoval --==[FReeZ]==-- — #23
    karma: 1 Thursday, 25.01.07, 12:59:35
  20. [20] Láďa r5cw78.net.upc.cz

    [18] Nejdřív bych si zjistil jaký je rozdíl mezi maskou (umask) a právy (chmod). Jsou to dvě prakticky opačné věci.

    odpověz na tento komentář karma: 0 Thursday, 25.01.07, 15:54:54
  21. [21] Squad_leader 83.197.broadband4.iol.cz

    PHP má snad nejlepší manuály vůbec.
    Bohužel zásoba nepříjemných "překvapení" je velká a kdo tvrdí, že ještě nikdy nenarazil na nějaký problém tak ten to dělá dodnes.

    odpověz na tento komentář karma: 0 Thursday, 25.01.07, 16:22:27
  22. [22] D1ce 83.74.broadband5.iol.cz

    odpovídá na llook — #14 odpovídá na Hornster — #17 Už mi to docvaklo, díky moc, holt měl jsem to nechat v hlavě vyhnít trochu déle, ještě než jsem se zeptal.

    odpověz na tento komentář karma: -2 Thursday, 25.01.07, 16:37:40
  23. [23] --==[FReeZ]==-- ip-89-102-167-110.karneval.cz

    odpovídá na Black Wolf — #19 omlouvam se, mate samozrejme pravdu stejne, jako rADo, za tento "prehmat" jsem utrzil 3 zaporne hlasy v karme, nyni uz budu ostrazitejsi.

    odpověz na tento komentář karma: -4 Thursday, 25.01.07, 17:20:08
  24. [24] tio289 18.204.244.87.in-addr.arpa

    Zdravím, páni, vysvetlené pekne, ale mohly ste sen dat nejaký ten solution ako to zmenit na servery. Po par hodinách googlení a hladaní som na to prisiel:)
    takze treba zmenit umask na 0000 v suboroch /etc/profiles a /etc/login.defs a potom pridat riadok umask 0000 do spustacieho scriptu apache (/etc/init.d/apache2)
    pak restart apache a frci to.

    odpověz na tento komentář
    1. na komentář reagoval tio289 — #25
    karma: 0 Monday, 11.05.09, 16:46:56
  25. [25] tio289 18.204.244.87.in-addr.arpa

    odpovídá na tio289 — #24 sorry je to /etc/profile :) pripadne ako to nepojde tak aj subor ~/.bashrc

    odpověz na tento komentář karma: 0 Monday, 11.05.09, 16:48:44

Přidejte nový komentář:

Pro přidání komentáře a hlasování se musíte nejdříve zaregistrovat nebo přihlásit.