Dotaz: php mkdir() neumi vytvorit slozku s pravy 777 ale jen 755

[wswolf]

Zdravim, mam dva dotazy. Nevite nekdo jak docilit toho aby slozka kterou vytvori PHP pomoci mkdir mela prava 777, ikdyz zadam: mkdir("nazevslozky",0777) stejne se vytvori 755.

A druhy dotaz je proc patri tato slozka uzivateli i skupine www-data, nebo spis jak zmenit tohoto uzivatele a skupinu. Mam server Ubuntu 8.04

Diky za rady

---

---

Odpovědi

[Filip Jirsák]

Když pod stejným uživatelem vytvoříte adresář a následně mu nastavíte práva na 0755 pomocí chmod normálně z shellu, práva se nastaví správně? Uživateli a skupině www-data patří pro to, že pod tímto uživatelem běží webový server.

[wswolf]

Jojo to se vytvoří správně. Ale z php to dělám z webové stránky, takže pod uživatelem www-data. Ale nechápu proč tam nejde nastavit 777...

[Filip Jirsák]

Ale jde o to i z toho shellu to vyzkoušet pod uživatelem www-data. Přepněte se na něj třeba pomocí su nebo příkazy spusťte přes sudo. Pokud to z shellu nepůjde, může jít buď o parametry připojení souborového systému, nebo SElinux (omezující daného uživatele). Pokud to z shellu půjde, může to být buď nějaká konfigurační volba PHP, nebo také SElinux (omezující Apache nebo PHP).

[Toman]

Za všechno může umask Takže je dobré to dělat např. takto:

function make_dir($dir, $perm) {
  umask(0000);
  mkdir($dir, $perm);
}

[Michal Kubeček]

Možná raději takto:

  function mkdir_perm($dir, $perm)
  {
    $old = umask(0000);
    mkdir($dir, $perm);
    umask($old);
  }

[Toman]

A nebo tak. Ale vy stejně asi budete vždy chtít nastavovat práva oproti masce 0000, takže je zbytečné, podle mne, to vracet do původního stavu. Pro funkci chmod budete také potřebovat "vynulovat" masku, apod.

[Michal Kubeček]

Na chmod() nemá umask vliv, umask omezuje jen práva v okamžiku vytvoření souboru nebo adresáře.

[Toman]

To by pak ale přeci nebylo potřeba vůbec používat umask, ale jen udělat mkdir a hned na to chmod. Nebo se pletu?

[pht]

To zavdává na problémy s race condition.

[Michal Kubeček]

Obecně určitě ano. Ale konkrétně v tomhle případě, kdy by se práva měnila z 755 na 777, by to nevadilo.

[Toman]

Díky za info - já to tedy doposud, pokud to bylo třeba, používal i před chmod, zbytečně.

[pht]

Obecně při takové změně práv by to vadilo. Pokud nějaký proces bude čekat, až se objeví danej adresář, aby to do něj něco šouplo, tak bude muset zároveň čekat na ten chmod, jinak se může stát, že to „někdy“ selže při zápisu.

[Michal Kubeček]

OK.

[Zaphod]

Tento príkaz pravdepodobne ovplyvňuje príkaz umask - odoberá práva vytvorenému súboru/adresáru. Bežne je nastavený na 022. Treba zmeniť na 000.

Hodnota sa dá zmeniť v ~/.profile užívateľa www-data. Štandartná hodnota je v /etc/profile.

[wswolf]

Pardon předtim jsem to nepochopil, zkusil jsem to z konzole a jde to, takže myslíte že to bude někde v PHP, nevíte kde to mám ale hledat? Dík

[Michal Kubeček]

Funkce se překvapivě také jmenuje umask()

[daan]

Ake prava ma nadradeny adresar? Pouziva dany server access control listy?

Tieto otazky mozes pomoct zodpovedat, ak sem posles vystup z ls -l na spominany nadradeny adresar - je mozme, ze vsetky podadresare automaticky zdedia prava/vlastnikov nadradeneho.

[wswolf]

Nadrazeny adresar ma prava 777 (to jsem zmenil hned na zacatku), access control list nevim co je ? majitel nadrazeneho adresar je honza (tedy ja) a nadrazeny adresar patri taktez do skupiny honza, nove vytvoreny adresar ma majitele www-data a patri do skupiny www-data.

[daan]

naozaj sem skus dat vystup z ls -l, to, ze je nieco "777" v niektorych pripadoch neznamena, ze je skutocne pristupny pre vsetkych. :)

ak vo vystupe mas nieco ako

drwxr-xr-x+

tak sa pouziva ACL - t.j. system, ktory definuje opravnenia o nieco striktnejsie a konkretnejsie vzhladom na jednotlivych vlastnikov a skupiny.
(je mozne nastavit aj spomina dedenie opravneni) btw, kto je hlavnym spravcom daneho serveru?

[wswolf]

Ja teda vubec nechapu na co vam bude ten vypis kdyz jsem sem vse napsal, ale pokud myslite ze to pomuze tak prosim:

/files/data$ ls -l
drwxr-xr-x 2 www-data www-data 4096 2009-10-26 11:44 pokus

Nadrazeny adresar:

/files$ ls -l
drwxrwxrwx 3 honza honza 4096 2009-10-26 10:42

Hlavnim spravcem jsem ja.
Ja bych rekl ze to bude nejaka ta konfigurační volba v PHP, jen nevim kde ji hledat. Ale take se mozna platu a je to uplne jinak...

[Filip Jirsák]

Konfigurační volby PHP bych hledal v konfiguraci PHP na vašem serveru, a jejich popis v dokumentaci PHP. V dokumentaci PHP máte také zdokumentovánu funkci mkdir(), ze které vede přímý odkaz na funkci umask(), kde je docela dlouhý popis i s příklady.

[Michal Kubeček]

Ja bych rekl ze to bude nejaka ta konfigurační volba v PHP, jen nevim kde ji hledat.

Odpověď už jste ale dávno dostal. Tím, že ji budete ignorovat, nepřestane být pravdivá.

[pht]

Za vytváření čehokoliv s právy 777 bych střílel.

[Zaphod]

V USA chodia admini ozbrojení. Asi preto vznikol parameter umask

[Michal Kubeček]

Hm… a co 1777, to jste ochoten vzít na milost? :-)

[Bilbo]

Na /tmp staci 1733

Ne vzdy musi uzivatele videt co vsechno je tam za bordel (ok, na svem osobnim stroji tam mam 1777 :)

[Michal Kubeček]

Teoreticky 1733 stačí, v praxi bych asi neriskoval, že jednoho dne, až to nebudu čekat, nějaká aplikace zkolabuje kvůli tomu, že bude chtít prohlížet obsah /tmp a když to nepůjde, nastanou problémy. On by bohatě stačil i skript, který se pokusí použít wildcards.

[pht]

Sticky bit je docela příjemná věc a 1733 už zavání bezpečím; pokud ovšem neděláte soubory s právy 777. Nejjednodušší je ale udělat privátní adresář buď /home/pht/tmp nebo /tmp/pht a je vymalováno.

Pokud se aplikace nedokáže vypořádat s absencí práv, které nepotřebuje, je na čase změnit aplikaci a nikoliv práva.

1337 je taky dobré pokud víte co děláte. :)

[Michal Kubeček]

Nejjednodušší je ale udělat privátní adresář buď /home/pht/tmp nebo /tmp/pht a je vymalováno.

Pro PHP ano, ale mluvil jsem spíš o linuxovém systému obecně.

[pht]

Jak se to liší?

[Michal Kubeček]

Pokud jde o jednoho uživatele a jeden program, tak není problém vyhradit mu jeho vlastní adresář pro pomocné soubory. Ale řešit tímto způsobem celý systém už tak jednoduché není.

[pht]

Ale jde to, jen se na to musí použít ty správné nástroje. Jak jsem říkal níže, existuje jich asi miliarda na sto způsobů. Začal bych u export TMP=...

Ad Vaše reakce

Co když půjde zrovna o důležitého démona a problém nenastane hned při spuštění, ale v nestřeženém okamžiku někdy později?

tak se to holt odhalí jako každé jiné selhání. Důležité věci je vhodné monitorovat. A ad

Kdyby nastavení práv na 1733 znamenalo nějaké významné posílení bezpečnosti

máte pravdu, že obecně to nějaký podstatný zisk není.

[Bilbo]

Stejne tak muze zkolabovat pokud si bude chtit precist treba /etc/shadow a ono to nepujde :) Osobne jsem /tmp chmodnuty na 1733 nebo 1773 uz parkrat videl a nezdalo se, ze by s tim byly v nejake aplikaci problemy. Vzhledem k tomu, ze v /tmp muze byt vselijaky bordel od ruznych programu od ruznych uzivatelu, tak se neda spolehat na to, ze tam neco bude nebo nebude.

[Michal Kubeček]

To je ale dost podstatný rozdíl. Soubor /etc/shadow není world-readable nikde (a pokud je, je to chyba), dokonce vznikl právě proto, aby nebyl world-readable (na rozdíl od /etc/passwd, který world-readable být musí). Oproti tomu /tmp má práva 1777 na naprosté většině systémů.

Netvrdím, že je v pořádku, když aplikace nebude fungovat, pokud jí nedovolím prohlížet obsah /tmp. Ale spoléhat na to, že na takovou dříve či později nenarazím, bych si prostě nedovolil.

[pht]

No, vzhledem k závažnosti problému a arzenálu nástrojů na jeho nápravu bych se nebál takový problém řešit teprv až nastane

[Michal Kubeček]

Na desktopu možná, ale na serveru bych to neriskoval. Co když půjde zrovna o důležitého démona a problém nenastane hned při spuštění, ale v nestřeženém okamžiku někdy později? Kdyby nastavení práv na 1733 znamenalo nějaké významné posílení bezpečnosti, tak by to bylo něco jiného, ale tohle není ten případ.