Jak nastavit oprávnění linux pro složku WWW?

Řešení 1:

Po dalším zkoumání se zdá, že další (možná lepší způsob), jak odpovědět, by bylo nastavit složku www takto.

1. sudo usermod -a -G developer user1 (přidat každého uživatele do skupiny vývojářů)
2. sudo chgrp -R developer /var/www/site.com/ aby tam vývojáři mohli pracovat
3. sudo chmod -R 2774 /var/www/site.com/ aby soubory mohli vytvářet/upravovat pouze vývojáři (jiný/svět může číst)
4. sudo chgrp -R www-data /var/www/site.com/uploads takže www-data (apache/nginx) mohou vytvářet nahrávání.

Od git běží tak, jak to uživatel volá, a pokud je uživatel ve skupině "vývojář", měl by být schopen vytvářet složky, upravovat soubory PHP a spravovat úložiště git.

Poznámka:V kroku (3):„2“ v 2774 znamená „nastavit ID skupiny“ pro adresář. To způsobí, že nové soubory a podadresáře v něm vytvořené zdědí ID skupiny nadřazeného adresáře (místo primární skupiny uživatele) Odkaz:http://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories

Řešení 2:

Nejsem si jistý, zda je to „správné“, ale na svém serveru dělám toto:

• /var/www obsahuje složku pro každý web.
• Každý web má určeného vlastníka, který je nastaven jako vlastník všech souborů a složek v adresáři webu.
• Všichni uživatelé, kteří spravují web, jsou zařazeni do skupiny pro web.
• Tato skupina je nastavena jako vlastník skupiny všech souborů a složek v adresáři.
• Všechny soubory nebo složky, které musí být zapsány webovým serverem (např. PHP), mají svého vlastníka změněn na www-data, uživatele, pod kterým Apache běží.

Mějte na paměti, že byste měli mít povolený prováděcí bit v adresářích, abyste mohli vypsat obsah.

Řešení 3:

Po dalším průzkumu se zdá, že git/svn NÁSTROJE NEJSOU problém, protože běží jako jakýkoli uživatel, který je používá. (Nicméně démoni git/svn jsou jiná věc!) Vše, co jsem vytvořil/klonoval pomocí git, mělo moje oprávnění a nástroj git byl uveden v /usr/bin což odpovídá této tezi.

Oprávnění Git vyřešeno.

Zdá se, že uživatelská oprávnění lze vyřešit přidáním všech uživatelů, kteří potřebují přístup k adresáři www, do www-data skupina, která Apache (a nginx) běží jako.

Zdá se tedy, že jedna odpověď tato otázka zní takto:

Ve výchozím nastavení /var/www je ve vlastnictví root:root a nikdo tam můžete přidávat nebo měnit soubory.

1) Změnit vlastníka skupiny

Nejprve musíme změnit skupinu adresářů www tak, aby byla vlastněna "www-data" místo "kořenové" skupiny

sudo chgrp -R www-data /var/www

2) Přidejte uživatele do www-data

Poté musíme přidat aktuálního uživatele (a kohokoli jiného) do skupiny www-data

sudo usermod -a -G www-data demousername

3) CHMOD www adresář

Změňte oprávnění tak, aby POUZE vlastník (root) a všichni uživatelé ve skupině „www-data“ mohli rwx (číst/zapisovat/spouštět) soubory a adresáře (nikdo jiný by k nim neměl mít ani přístup em> ).

sudo chmod -R 2770 /var/www

Nyní budou všechny soubory a adresáře vytvořené libovolným uživatelem, který má přístup (tj. ve skupině „www-data“), čitelné/zapisovatelné pomocí Apache a tedy php.

Je to správně? A co soubory, které vytváří PHP/Ruby – mohou k nim uživatelé www-data přistupovat?

Řešení 4:

Lepkavost není dědění oprávnění. Lepkavost v adresáři znamená, že pouze vlastník souboru nebo vlastník adresáře může tento soubor v adresáři přejmenovat nebo smazat, přestože oprávnění říkají jinak. Tedy 1777 na /tmp/.

V klasickém Unixu neexistuje žádná dědičnost oprávnění založená na souborovém systému, pouze na umask aktuálního procesu. Na *BSD nebo Linuxu s setgid v adresáři bude pole skupiny nově vytvořených souborů nastaveno na stejné jako pole nadřazeného adresáře. Pro cokoli dalšího se musíte podívat do ACL s 'výchozím' ACL na adresáře, které vám umožňují mít zděděná oprávnění.

Měli byste začít definováním:* kteří uživatelé mají přístup k systému* jaký je váš model ohrožení

Pokud například provozujete webhosting s více zákazníky a nechcete, aby si navzájem viděli soubory, můžete použít společnou skupinu „webcusts“ pro všechny tyto uživatele a režim adresáře 0705. proces webového serveru (ne v "webcusts") uvidí Ostatní perm a bude povoleno; zákazníci si navzájem nevidí soubory a uživatelé si mohou zahrávat se svými vlastními soubory. To však znamená, že v okamžiku, kdy povolíte CGI nebo PHP, máte abyste se ujistili, že procesy běží jako konkrétní uživatel (což je každopádně dobrá praxe pro více uživatelů na jednom hostiteli, kvůli odpovědnosti). V opačném případě by si zákazníci mohli navzájem pohrávat se soubory tím, že by to dělalo CGI.

Pokud je však uživatel za běhu webu stejný jako vlastník webu, máte problémy s tím, že v případě bezpečnostní díry ve skriptu nejste schopni ochránit obsah před zneužitím. Což je místo, kde vyhrávají vyhrazení hostitelé, takže můžete mít uživatele za běhu odlišného od vlastníka statického obsahu a nemusíte se tolik starat o interakci s ostatními uživateli.

Řešení 5:

Věřím, že nejlepší způsob, jak toho dosáhnout, je používat Posix ACL. Práce s nimi je pohodlná a nabízejí všechny funkce, které potřebujete.

http://cs.wikipedia.org/wiki/Access_control_list#Filesystem_ACLs