Jak nastavit práva /var/www/html pro víc uživatelů

[xmms]

Potřebuju mít několik sajtů, pro každého uživatele zvlášť v /var/www/html/username nebo v /home/username

Jak se u toho v praxi nastavují práva, aby do toho mohlo apache a každý uživatel (přes ftp nebo ssh) jen do svého adresáře? Jde o to, že kdokoliv si může vyrobit php skript, kterým se dostane i do adresářů jiných uživatelů (protože běží pod uživatelem apache) a to nechci. PHP skript webu jednoho uživatele se nesmí dostat k souborům jiných uživatelů.

[Reklama]

[_Jenda]

Musíš pustit zvláštního FastCGI PHP workera pro každého uživatele. (možná to v apachi s mod_php nějak jde i bez toho, já apache nepoužívám, mám lighttpd)

[Kit]

https://httpd.apache.org/docs/2.4/howto/public_html.html

[jouda2]

https://www.php.net/manual/en/ini.core.php#ini.open-basedir
ale mnohem lepší mi připadá pouštět php-fpm a na per-user bázi (navíc se pak daleko líp dá např. omezit počet workerů etc. a indián pak nemusí jet v preforku, což se dost výrazně projeví i u statického obsahu)

[Miroslav Šilhavý]

S bezpečností se dá jít mnohem, mnohem dál. FPM běžící pod odděleným uživatelem je IMO základ. Nicméně, společný uživatel je pak na apache / nginx, takže pokud chcete mít oddělená práva i pro čtení statických souborů, stojí za to mít i oddělené instance pro webserver, do kterých provoz rozhazuje reverzní proxy. Je to výhodné i pro činění konfiguračních změn. Např. SSL, komprese, ... jsou jen na instanci reverzní proxy, naopak moduly v apachi (nginxu) se pak nemusí povolovat všem, ale jen uživatelům, kteří je potřebují. Lze nastavit různou prioritu pro instance (může se hodit, aby např. vývojový web měl méně prostředků, než produkční).

Pak je také dobré nastavit umask, aby others neměli žádná práva. To pomůže taky hodně moc, zejména, pokud to vychází už od home adresáře. V takovém případě se do toho celého ještě přidává "složitost" s nastavením ACL - aby apache a fpm mohly do adresáře uživatele a navzájem. Ani apache, ani FPM nepotřebují write oprávnění vyjma tempů, uploadu a sessions adresářů. V celém webu (včetně tempů, uploadů, sessions) je dobré nastavit přímo noexec.

Podle mě je to ale dost komplikované na to, aby nešel napsat do diskuse nějaký návod. Bez pochopení, jak to funguje, se stejně nedá bezpečnost udržovat a kontrolovat. Doporučil bych, pokud s tím nechcete ztratit opravdu hodně času učením se (což je samozřejmě taky dobrá cesta), vzít nějaký bezplatný či placený panel pro správu hostingů. Není tam vyřešeno 100 % toho, co se dá, ale většinu mají zvládnutou.

[Reklama]

[xmms]

Open-basedir mi udělá jen stránku typu mujsite.com/~user. shell_exec('whoami') v php vrací www-data (mám ubuntu 18). Funguje nastavení APACHE_RUN_USER v /etc/apache2/envvars, ale to je globální.
Zkouším nějaké návody na SuexecUserGroup a fast cgi a nedaří se mi to udělat. Znáte někdo příklad funkčního nastavení pro nějaký VirtualHost? Chci mít pro každý virtualhost jiného usera, pod kterým pojede jeho php skript.

[Miroslav Šilhavý]

Open-basedir mi udělá jen stránku typu mujsite.com/~user. shell_exec('whoami') v php vrací www-data (mám ubuntu 18). Funguje nastavení APACHE_RUN_USER v /etc/apache2/envvars, ale to je globální.
Zkouším nějaké návody na SuexecUserGroup a fast cgi a nedaří se mi to udělat. Znáte někdo příklad funkčního nastavení pro nějaký VirtualHost? Chci mít pro každý virtualhost jiného usera, pod kterým pojede jeho php skript.

Je to poměrně dost nastavování, ale jde to.
Nejprve si nainstalujete třeba nginx jako reverzní proxy. Založíte uživatele pro běh proxy a nastavíte, aby pod ním běžel nginx. Osobně doporučuju udělat si na to extra instanci, protože pak se nestane, že si s aktualizací přepíšete něco v /etc/nginx.

Pak založit uživatele pro instanci php-fpm, uživatele pro apache té instance a uživatele, který bude nahrávat soubory.

Apache (v rámci systemd) založit novou instanci, tu nechat naslouchat na 127.0.0.1 a nějakém portu. Celého apache nechat běžet pod extra uživatelem, kterého jste založil (viz odstavec výše).

Na nginx proxy nastavit, který FQDN se mají přesměrovat na 127.0.0.1:port.

V php-fpm nastavit nový pool, který poběží pod uživatelem, kterého jste založil (viz výše).

Tím máte hotové odělení práv od sebe. V tento moment začnete budovat práva mezi sebou, aby jednotlivé části směly vůči sobě to, co chcete. Tím je obvykle přidávání ACL, aby např. apache mohl ke statickým souborům webu, aby php-fpm mělo read-only přístup do aplikace samotné a zápis jen do složek, kam se ukládají provozní data, tempy, ...

Je to poměrně hodně práce a neexistuje na to kuchařka.

Jako první tip: naučte se spouštět více instancí Apache (přes systemd), a naučte se spouštět více instancí PHP-FPM (přes pooly v php-fpmd) a přiřaďte jim extra uživatele (systémové, bez možnosti loginu, bez home, ...) a extra skupiny.

[xmms]

Já jsem doufal, že to půjde nějak jednoduše nastavit direktivou SuexecUserGroup user1 user1 pro každý virtualhost. Čekal jsem, že v dnešní době bude mít nejnovější apache už takové věci dávno v sobě.

Děkuji všem za snahu, ale do proxy a různých instancí apache na různých portech se pouštět nechci.
A jak tohle v praxi řeší webhostinogové firmy, které mají tisíce zákazníků? Těma fpm poolama nebo nějak jinak?

[Miroslav Šilhavý]

Já jsem doufal, že to půjde nějak jednoduše nastavit direktivou SuexecUserGroup user1 user1 pro každý virtualhost. Čekal jsem, že v dnešní době bude mít nejnovější apache už takové věci dávno v sobě.

Nemá, a nedá se to ani očekávat. Součástí bezpečnosti je i segregace oprávnění, takže by nebylo příliš moudré to nakoncentrovat do rukou apache, či čehokoliv jiného. Pro takové to domácí žvýkání stačí jednoduché nastavení, nepotřebujete oddělovat oprávnění. V produkci by se to už mělo, ale na to, co vím, žádná distribuce nedává řešení out-of-box.

Open source dobře funguje na sdílení programového kódu, ale opravdové know how se už tolik netroubí do světa, a tak internetové návody jsou spíš entry-level.

Ve větším se to řeší přes produkty typu Plesk. cPanel apod., ale obvykle je to stejně plné kompromisů, protože spousta PHP aplikací je napsaná špatně a vyžadují prakticky plná oprávnění.

[jouda2]

Já jsem doufal, že to půjde nějak jednoduše nastavit direktivou SuexecUserGroup user1 user1 pro každý virtualhost. Čekal jsem, že v dnešní době bude mít nejnovější apache už takové věci dávno v sobě.

No a i to je přesně důvod, proč se často od Apache ustupuje směrem k nginx, který je proti němu minimalistický, zato se chová mnohem rozumněji pod vysokou zátěží.

Suexec pro sdílený hosting? Takže každý request do PHP bude znamenat nějakou pipe(), fork() (~mikrosekunda), jenže následuje exec() který je docela drahý, pak nějaké ty inity, kontroly environmentu etc. a teprve pak může nabíhat php jako takové. To fakt nechcete.

Jak tu mnozí píšeme, php-fpm je nejsprávnější snadná cesta - můžete mít per-user workera který už je inicializovaný, má už usera, limity, chroot etc., v lepším případě přehodíte request jednomu z flákajících se childů, v tom horším se holt fork()ne (už inicializovaný), apache/nginx se k tomu chová standardně jako proxy. Návodů na netu jsou mraky, basic konfigurace třeba hned druhá z kachny https://develike.com/en/articles/configuring-apache-to-support-php-fpm-on-debian-ubuntu

(vyšší bezpečnost pak už bude něco čemu se dneska říka kontejnerizace, ať už v jakékoli podobě, počínaje php-fpm v chrootu, nejlépe doplněné o ulimit/novější cgroups (a iptables/nftables v OUTPUTu na uid), přes skutečný kontejner - tady se dá vymýšlet celá škála řešení jak to udělat - a skončíte asi u virtualizovaného webu s dedikovanou IP a corem, horní limita je samozřejmě dedikovaný server)

[xmms]

Tak už jsem pochopil, jak nastavit php-fpm pooly pro víc uživatelů a každý má na svém sajtu ten svůj. A funguje, každý si pouští php po svým userem. To zatím stačí, takhle jsem to potřeboval.

Zatím díky za posun správným směrem.

[McFly]

Dlouhé roky používám MPM_ITK, např. https://www.howtoforge.com/running-vhosts-under-separate-uids-gids-with-apache2-mpm-itk-on-debian-etch

[RDa]

Ja na ty PHP bezici pod realnym userem pouzivam mpm_peruser_module ale vypada jako obsolete a v novsim Apache neni.
Ma to primou nahradu, nebo neco na co jde zmigrovat konfiguraky bez znatelneho poklesu vykonu?

[Rob Ros]

Ja na ty PHP bezici pod realnym userem pouzivam mpm_peruser_module ale vypada jako obsolete a v novsim Apache neni.
Ma to primou nahradu, nebo neco na co jde zmigrovat konfiguraky bez znatelneho poklesu vykonu?

Proc na to pouzivat Apache modul, kdyz staci nastavit ruzne PHP-FPM pooly, do kterych pak pozadavky z Apache spravne nasmerujete? Nebo mi neco unika?

[RDa]

Ja na ty PHP bezici pod realnym userem pouzivam mpm_peruser_module ale vypada jako obsolete a v novsim Apache neni.
Ma to primou nahradu, nebo neco na co jde zmigrovat konfiguraky bez znatelneho poklesu vykonu?

Proc na to pouzivat Apache modul, kdyz staci nastavit ruzne PHP-FPM pooly, do kterych pak pozadavky z Apache spravne nasmerujete? Nebo mi neco unika?

A tam funguje $SERVER transparentne? Treba pouziti proxy prinasi dalsi praci s backendem, ktery musi prohledavat extra hlavicky, takze neco "zazdit" hloub je obcas problem. A proti vsem tem out-of-process udelatkum (cgi/fcgi..) mam vyhrady z duvodu kopirovani/pajpovani vystupnich dat mezi procesy.

Nekdo holt resi kadenci dotazu / opcode cache.. me se nezda overhead nad daty. Ale nekam bude potreba jit, nez ten starej indian prestane byt podporovany, na FPM se podivam.