Dotaz: Práva

[georgo23]

Potřebuji vyřešit následovné, přidat uživatele, který bude mít práva k složce www-data. Vždy jsem řešil jenom roota, asi je to špatně, nicméně měl jsem vždy jen povolené přístupu z konkrétních IP. No nyní potřebuji vytvořit uživatele, který se pomocí ssh zaloguje a zároveň bude moci edtitovat obsah v adresáři /var/www/html*. Projel jsem kde co, a vážně nejsem z toho chytrý. Měl jsem za to, že bude stačit, aby byl ve stejně skupině.. no omyl sice vídím ale jen pro čtení. Vím že je zde i možnost skrze sudo, ale zase nechci mu dát úplně plný rozsah. Prosím tedy o návod jak na to. děkuji.

---

---

Odpovědi

[MP]

A kristalovou kouli na pouzite technologie uz jste pro abclinuxu poridil?

[georgo23]

Moc nerozumím, proč máte potřebu takové odpovědi? Jak vidíte níže, kolega bez problému odpověděl na můj dotaz a to v plném rozsahu, za co mu tímto děkuji. Možná jste ne úplně pochopil smysl fóra, či prosby o radu. Možná jen máte kus té české nátury sarkasticky a arogantně urážet, nevím ... nicméně, možná bych být Vámi přehodnotil chování zde, nebo přinejmenším v tomto vlákně.

[j]

Jo a uplne blbe, webserver ma typicky totiz RO pristup a RW jen do vyhrazenych adresaru. Z velmi dobryho duvodu. A menit to je napad hodnej totalniho idiota!

A tebe by taky bylo potreba nakopnout, protoze jak ti bylo receno, kdyz chces neco vedet, je treba rict s cim to resis. Jako arogantni kreten se tu chovas leda ty!

[georgo23]

Soubory v Linuxu (a unixech obecně) mají tři sady oprávnění: pro vlastníka, skupinu a ostatní. Každá sada oprávnění jsou tri bity: čtení, zápis a spuštění souboru či vstup do adresáře.

Potřebuješ udělat dvě věci:

1. Přidat uživatele do skupiny www-data: adduser uživatel www-data

2. Nastavit odpovídajícím souborům požadovaná oprávnění, tedy nastavit skupině práva k zápisu: chmod g+w -R /var/www/html

Pak je ještě jedna věc zvaná umask, tedy maska oprávnění nově vytvářených souborů. Pro takovýto setup je dobré nastavit webserveru masku z 0022 na 0002, tedy aby nové soubory měly povolen zápis skupinou. Predpokládám, že webserver už běží jako uživatel www-data, skupina www-data.

Asi však narazíš na to, že se ti budou uživatelé porůznu přetahovat o oprávnění, když jeden uživatel něco vytvoří a druhý to nebude moct upravit. Na to také pomůže nastavit umask.

Také se hodí ještě nastavit setgid bit adresářům, aby nové adresáře a soubory "dědily" skupinu nadřazeného adresáře: chmod g+s -R /var/www/html

[jiwopene]

Nepřidává se uživatel do skupiny pomocí usermod -a -G $skupina $uzivatel?

[Josef Kufner]

Těch možností je povícero. Stačí to i prostě jen připsat do /etc/groups.

[debian+]

+ prihlasit a odhlasit.

[Kit]

Tohle řeším tak, že vlastnictví adresáře www-data převedu na uživatele, který se o stránky bude starat - zpravidla sebe. Pak nastavím všem souborům práva 604, adresářům 705. Tedy kromě adresářů temp a log - těm dám 777, protože do nich Apache potřebuje práva pro zápis. Tím je zpravidla hotovo a sudo může jít spát.

[Filip Jirsák]

Podle mne je lepší pro obsah webu místo uživatele použít skupinu, která se o to bude starat – může to být víc uživatelů. Ale princip je stejný – správce (uživatel nebo skupina) má práva rw- na soubory a rwx na adresáře, web server k souborům přistupuje jako ostatní s právem r-- resp. r-x pro adresáře. Na adresáře je pak dobré nastavit sgid bit, aby se dědila skupina z rodičovského adresáře.

Takže pak oprávnění mohou vypadat např. takhle:

drwxrwsr-x  root www-edit web/

Do log adresáře webového serveru bych nedával právo zápisu všem, ale jen uživateli, pod kterým běží webový server.

[MP]

Tohle taky neni uplne dobre, protoze zpristupni obsah slozek vsem uzivatelum (i kdyz jen ro).

Zakladem je 750 owner1:www-data s tim, ze navic g+s. Takze owner2 neuvidi obsah owner1.

[Josef Kufner]

Toto v podstatě nemá řešení, alespoň ne jen s tradičními unixovými právy. Zápisu webserverem jde zabránit pomocí ACL nebo pomocí AppArmoru. Pak stačí použít skupinu www-data, jak jsem popsal výše a bude to bezpečné. Bez omezení zápisu závisí bezpečnost na nastavení a děravosti webserveru. Pokud je tam jen statický obsah, tak je to v pohodě. Pokud nějaká děravá aplikace, tak ani omezení zápisu nemusí stačit.

Pořádné řešení jde postavit na Gitu a CI, kdy uživatelé commitují do Gitu, zodpovědná osoba hlídá, že tam necommitují blbosti a CI to pak automaticky vystavuje na web. To "hlídá" může mít více podob, může to být třeba jen chráněná větev, kde nejde měnit historii, nebo může aktivně kontrolovat a mergovat. Ale to už se dostáváme úplně někam jinam.

[Filip Jirsák]

Záleží na tom, zda jsou na tom systému ještě jiní zajímaví uživatelé. Pokud ano, můžete třeba root webu přivlastnit uživateli apache (nebo www-data, záleží na tom, jak se jmenuje u vás) a dát mu práva r-x, pro skupinu www-edit práva rwx a ostatním nic. Tím pádem se dovnitř dostane jen uživatel apache a www-edit a pak už nevadí, že „ostatní“ mohou číst, protože „ostatní“ jsou jen apache nebo www-edit. Samozřejmě ale nesmí dovnitř vést nějaký hardlink, kterým by to šlo obejít.

[MP]

Zajimavy zpusob. Ja to pres "user":www-data mam resene proto, ze i php-fpm bezi primo pod "user" a timpadem vsechny slozky/soubory jsou "user":www-data, nemluve o tom, ze se pak da snadno resit i neco jako 400, kdy webserver nema vubec pristup k citlivym souborum.

[Josef Kufner]

Citlive soubory by vubec neměly být v document root webserveru. Obvykle se to řeší tak, že webserver má nastavený document root do podadresáře toho, kde běží PHP. Takže konfiguráky a podobné věci webserver nepošle klientovi i kdyby se náhodou rozdrbala oprávnění nebo pri upgradu vypadla konfigurace PHP.

[Filip Jirsák]

Pokud to chápu správně, PHP u vás běží pod uživatelem, který má právo měnit soubory webu. To je podle mne špatně, tím otvíráte bránu pro všechny ty útoky na chyby v PHP aplikacích, které umožňují zapisovat jim, než bylo zamýšleno, a dát tak na web svůj škodlivý kód. Jasně, některé aplikace to potřebují, některé to potřebují pro nějakou funkcionalitu (a pak bych zvážil, zda je opravdu potřeba), ale kvůli tomu bych ta práva nedával všem.

Pokud web server přistupuje k souborům přes práva --o, stačí pro --o nastavit práva --- (0) a web server se k souboru nedostane.

[MP]

Zalezi na uhlu pohledu.

Php bezici pod vlastnim uzivatelem ma vlastni pool, coz ma ve vyhody v sdilenem prostredi. Na serveru se to pohybuje pod danym uzivatelem. Nemusim opakovane resit, ze si vyvojari rozkopou prava dedicnosti pres acl.

Ono reseni vhodnych prav je vzdy komplexni vuci use-case. Navic, kdyz do toho zacne mluvit automatizace. Na solo serveru pouzivam acl a i pres "default" acl casto dojde k tomu, ze vyvojari seberou skupine pravo zapisu a prestane to fungovat kvuli tomu, jak funguje maska. Navic, jestli si mam vybrat, zda zapisuje www-data nebo "user", pod kterym bezi to php, tak radeji vazne "user" - zkuste resit stejny mapovani uid pro nfs u systemovych uzivatelu...

[Filip Jirsák]

Nerozumím, jak běh PHP pod vlastním uživatelem souvisí s tím, zda ten uživatel má nebo nemá páva zapisovat do souborů webové prezentace (ať už statických, nebo PHP).

[debian+]

Ne nahodou 770 pre priecinky, pre subory 660? A ten iny uzivatel ma mat aj editovat.

[Boban]

Pěkný rady. A co takhle už se přesunout do roku 2020 a použít normálně ACL?

[Filip Jirsák]

Já jsem neměl odvahu zkoušet to, jestli už to použitelně funguje. Tj. jestli se ACL budou dědit tak, jak by člověk očekával, z nadřazeného adresáře do podřízeného. A to bez ohledu na to, jakým způsobem soubory vznikají – zda je vytvořím ve vimu, zkopíruju přes SFTP, z Gitu, vytvořím webovou aplikací… Už bude drtivá většina aplikací při přesouvání a kopírování souborů nastavovat ACL podle cílového adresáře, nebo tam nechají ta původní? To je totiž klíčové – správci webu nechci vysvětlovat, že při jakékoli úpravě souborů musí na konci ještě spustit setfacl a opravit tak práva.

[Boban]

Používám ACL už spousty let na různých souborových systémech pro různá nasazení včetně webu. Dědění funguje naprosto perfektně, není potřeba žádná podpora v aplikaci. Jediné čemu jsem nepřišel na chuť jsou NFS4 ACL.

[Filip Jirsák]

Dědění sice funguje technicky naprosto perfektně, ale pro uživatele je to nepoužitelné.

~/tmp/acl % setfacl -d -m u:www-data:r .
~/tmp/acl % getfacl .
# file: .
# owner: filip
# group: filip
user::rwx
group::rwx
other::r-x
default:user::rwx
default:user:www-data:r--
default:group::rwx
default:mask::rwx
default:other::r-x

~/tmp/acl % touch /tmp/test
~/tmp/acl % mv /tmp/test ./
~/tmp/acl % getfacl test
# file: test
# owner: filip
# group: filip
user::rw-
group::rw-
other::r--

Vážně nemůžu editora webu nutit, aby po každé změně ještě nastavoval práva…