Dotaz: Apache + Perl + suexec/cgiwrap/whatever

[Jakub Lucký]

Ahoj

řeším zásadní problém, snažím se rozjet Apache s Perlem, ale zásadní podmínkou je fakt, že se bude používat oddělení práv, tedy že si každý uživatel bude pěkně spouštět své skripty se svými právy buď na základě Virtualhostů nebo za základě vlastnictví skriptu...

Testoval jsem zatím speedyCGI, které ale odmítá strávit suexec a fcgid, které zase umře s kryptickou chybou:

[warn] (104)Connection reset by peer: mod_fcgid: read data from fastcgi server error.
[error] [client 78.102.107.216] Premature end of script headers: index.pl
[notice] mod_fcgid: process /home/www/perl/index.pl(10633) exit(communication error), terminated by calling exit(), return code: 255

Jakákoliv rada jak dosáhnout kýženého výsledku je velmi vítaná, děkuji za ně..

---

---

Odpovědi

[Jakub Lucký]

nikdo neví?

[pht]

Kryptická je nejen chyba ale i Váš dotaz. Ptáte se na to, jak sprovoznit suexec a zároveň speedycgi/mod_perl/atd? Odpověď je: nelze.

[Jakub Lucký]

Tak to se omlouvám za špatně formulovanou otázku...

Potřebuji do Apache nacpat Perl, který se bude spouštět s právy uživatele (buď definovaného ve Virtualhostu, nebo podle owner-group jako v suPHP), technologie, které jsem v dotazu vyjmenoval jsou v podstatě ty, které jsem se pokusil donutit fungovat a hledám jakoukoliv funkční variantu.

mod_perl to evidentně neumí, v každém FAQ to důrazně píšou

u speedycgi jsem takovou zmínku nenašel, ale včera jsem narazil na velmi neoficiální projekt speedysu, který by to měl nějak implementovat, ale zatím to není v žádné distribuci a implementace bych se trochu bál..

fcgid umírá na onom kryptickém erroru...

Takže můj dotaz je nakonec tak trochu dvojdotaz: Jak zprovoznit Fcgid se suexec nebo existuje nějaké jiné řešení?

[pht]

A co normální CGI? Na tom suexec funguje.

[Jakub Lucký]

klasické CGI mi funguje, ale nesuexecuje Definice virtualhost

<VirtualHost *:80>
     ServerName perl.domain.tld
     DocumentRoot /home/www/domain.tld/perl/
     SuexecUserGroup domain domain
     AddHandler cgi-script .pl
     SetHandler cgi-script
     Options +ExecCGI
</VirtualHost>

Ale běží to pod UID 33 (aspoň podle perlovský $< $>)

#!/usr/bin/perl -w
print "Real UID".$<."\n";
print "Effective UID".$>."\n";
print "Real GID".$(."\n";
print "Effective GID".$)."\n";

[pht]

A co je 33? Pokud to je něco jako "apache", tak by web server měl běžet pod rootem aby byl schopen setuidovat.

[Jakub Lucký]

33 je skutečně Apache... Ale třeba takové suphp umí tuto funkcionalitu i přes Apache běžící jako UID 33, takže to by neměl být ten problém (předpokládám)...

[pht]

Ach jo.

[suphp] [search]

suPHP is a tool for executing PHP scripts with the permissions of their owners. It consists of an Apache module (mod_suphp) and a setuid root binary (suphp) ...

Tak to máte prašť jak uhoď. Taky existuje něco jako suidperl. (Hledejte.) Bejt váma tak na ty virtualhosty spustím na každý zvlášť apache pod svým uživatelem.

[Jakub Lucký]

To by právě měl dělat ten suexec... pokud umí stejnou funkcionalitu pro fastcgi, kde se spouští php-cgi, tak proč by totéž nedělal pro perl, který je zvyklý pracovat jako CGI?

[VSi]

Zapíše suexec něco do logu /var/log/apache2/suexec.log?

[Jakub Lucký]

právě že nic...

[VSi]

Tak to je zvláštní. Problémy u suexecu jsou celkem často - obvykle je napevno zkompilováno omezení na minimální UID, document root musí začínat na /var/www (nevadí ale třeba, když je to symlink jinam)... ale vždy to zapíše chybu do logu a klientovi vrátí Internal server error.

Takhle to vypadá, že se suexec vůbec nektivuje. Pamatuji si, že ve starších verzích se musel ručně nastavit SUID bit na binárce suexecu, nebo ji dokonce někam přesunout, jinak to nefungovalo.

Nic ohledně suexec není ani v Apache error logu? Pokud je v konfiguraci ta volba SuexecUserGroup a nehlásí to chybu, je suexec modul určitě načtený, ale nefunguje.

[Jakub Lucký]

whocares:~# apt-get install apache2-suexec-custom 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
apache2-suexec-custom is already the newest version.

whocares:~# a2enmod suexec
Module suexec already enabled

whocares:~# /etc/init.d/apache2 restart
.

whocares:~# ls -l /usr/lib/apache2/suexec 
-rwsr-xr-- 1 root www-data 15192 2009-11-14 22:09 /usr/lib/apache2/suexec

Já právě už fakt nevím... Možná otázka, co by mělo být v /etc/apache2/suexec/*

[VSi]

Aha, zkusil bych začít s balíkem apache2-suexec. Ta -custom verze se nejspíš musí nějak nastavit, a nějaká dokumentace k tomu zrovna moc není...

[Jakub Lucký]

No, to bude asi ten problém... Asi se pustím do perverzního inženýrství, protože apache2-suexec není úplně lákavý, vzhledem k zakompilovanému nastavení

Provides the standard suexec helper program for mod_suexec. This version is compiled with document root /var/www and userdir suffix public_html. If you need different settings, use the package apache2-suexec-custom.

[VSi]

To výchozí nastavení ne vždy vyhovuje, ale dá se s tím žít. Nevím pro jaké prostředí to potřebujete, ale pro běžný hosting (tj. hromada <VirtualHost> podle domén) to znamená, že jakýkoliv <DocumentRoot> musí začínat na /var/www - dá se to obejít tak, že /var/www je symlink kamkoliv jinam.

Pokud jde o použití <Userdir> (tj. weby systémových uživatelů přistupné obvykle jako ~/login) tak tam je pevné omezení, že veřejný adresář bude ~/public_html

[Jakub Lucký]

To, co já bych potřeboval, je spouštět všechny skripty v /home/www/$USERNAME/domain.tld/anything/ pod uživatelem $USERNAME, přičemž domén může být v této složce víc... A to myslím nepůjde...

[VSi]

Myslím, že to nebude takový problém:

- symlink /var/www > /home/www

- v konfiguraci apache (/etc/apache2/sites-enabled/...) bude pro každou domain.tld neco jako:

<VirtualHost IP_ADDR:80>
    ServerName domain.tld
    ServerAlias *.domain.tld
    ServerAlias jinadomena.tld
    DocumentRoot /var/www/$USERNAME/domain.tld
    <Directory /var/www/$USERNAME/domain.tld>
        Options Indexes FollowSymLinks MultiViews ...
        AllowOverride ...
        Order allow,deny
        allow from all
    </Directory>
    SuexecUserGroup $USERNAME skupina
...

- alternativně, pokud nebudete potřebovat aby na tu jednu složku směřovalo víc domén (nevyužijete ServerAlias jinadomena.tld) to lze zjednodušit tak, že bude DocumentRoot /var/www/$USERNAME a do jednotlivých složek se požadavky zařadí pomocí mod_rewrite pravidel

- pokud jde o nějaký "bežný" hosting, tak si připravte i řešení pro adresáře na subdomain.domain.tld, nejflexibilnější řešení je opět pomocí mod_rewrite

[trekker.dk]

Místo toho symlinku jde buď namountovat data přímo do /var/www nebo použít ten -custom balíček, kde se nechá nastavit místo /var/www něco jiného

[Jakub Lucký]

problém je v tom, že pro jednoho uživatele je možné definovat pouze jeden document root...

No, tak zatím, k mému velkému zklamání, Perl asi nebude, až se odhodlám k přechodu na apache2-mpm-itk, tak možná pak...

Rozhřešení pro náhodné kolemjdoucí:

Perl se suexec obecně jde vyřešit, příjemné naznačení je v příspěvku na který reaguji, potíží mohou být pokusy používat jednoho uživatele na více domén

[Jakub Lucký]

Každopádně děkuji diskutujícím za rady

[VSi]

Nevím, kde vidíte ten problém. Ten document root u suexecu se kontroluje jako PREFIX Apache DocumetRoot - zkuste si to. Klidně lze mít default suexec nastavení (docroot /var/www) a Apache VirtualHost má nastaven DocumentRoot /var/www/co/ko/liv

Nastavení, které jsem naznačil používám na produkčním serveru bez problémů. Myslím, že přesně tak, jak potřebujete: apache+suexec+(php/perl/...), systémoví uživatelé user1 ... userN, domény domain1.tld ... domainM.tld - každé doméně je přiřazen 1 z uživatelů, jeden uživatel může být přiřazen klidně k více doménám.

[VSi]

Ještě doplním, že toto řešení používám na Debianu Lenny s balíčkem apache2-suexec, tj. bez potřeby jakékoliv konfigurace v /etc/apache2/suexec/...

Více domén (VirtualHost) pod jedním uživatelem rozhodně není problém (vyzkoušeno ).

[Jakub Lucký]

Aha... už mi to dochází, to by možná šlo... Jdu to otestovat

[Jakub Lucký]

Tak popsaný postup funguje... Děkuji... Jinak slibuji lehký benchmark jak Perlu, tak PHP s jednotlivými suid metodami...

[Jakub Lucký]

suexec byl evidentně naprogramován s jediným cílem... přivést člověka, který se to pokusí zprovoznit na trošku exotické konfiguraci k totálnímu šílenství (nebo aspoň převést na víru, modlení, nebo programování v C)

Z oficiální dokumentace

For security and efficiency reasons, all suEXEC requests must remain within either a top-level document root for virtual host requests, or one top-level personal document root for userdir requests. For example, if you have four VirtualHosts configured, you would need to structure all of your VHosts' document roots off of one main Apache document hierarchy to take advantage of suEXEC for VirtualHosts. (Example forthcoming.)

Z manpage

CONFIGURATION If suexec is called by a user with name ’username’, it will look into /etc/apache2/suexec/username for configuration. If the file does not exist, suexec will abort. By creating several config files, you can allow several different apache run users to use suexec.

The first line in the file is used as the document root (/var/www in the standard suexec) and the second line in the file is used as the suffix that is appended to users’ home directories (public_html in standard suexec).

If any of the lines is commented out (with #), suexec will refuse the corresponding type of request. It is recommended to comment out the userdir suffix if you don’t need it.

Jdu se ještě podívat do některých věcí, jakým způsobem se to řeší u toho PHP/fastcgi, protože tohle jinak asi nepůjde... Potřebuju víc domén/složek s funkčním suexec, a to asi neprojde...

[trekker.dk]

Ta -custom verze se nejspíš musí nějak nastavit, a nějaká dokumentace k tomu zrovna moc není...

Dokumentace je ve /etc/apache2/suexec/www-data, když se to nainstaluje.

/var/www
public_html/cgi-bin
# The first two lines contain the suexec document root and the suexec userdir
# suffix. Both features can be disabled separately by prepending a # character.
# This config file is only used by the apache2-suexec-custom package.

Umožňuje to změnit adresáře, které jsou jinak nastavené natvrdo

[trekker.dk]

Ptáte se na to, jak sprovoznit suexec a zároveň speedycgi/mod_perl/atd? Odpověď je: nelze.

Můžu se zeptat, čím to je? php-fcgid-suexec funguje v pohodě - v Debianu je to i s Googlením práce na hodinku, co je u perlu špatně?

[pht]

You can't suid a part of a process. mod_perl lives inside the Apache process, so its UID and GID are the same as those of the Apache process.

To není vlastnost perlu, ale správy procesů a práv v UNIXu.

[trekker.dk]

Jenže já nemluvím o mod_perl. U výše uvedené kombinace se interpretr PHP spouští jako samostatný proces (pod zvoleným uživatelem) a o předání výsledků zpět do Apache se stará mod_fcgid; zajímalo mě, proč by něco podobného nemělo jít u perlu.

[pht]

Ten mod_fcgid neznám.

Čím se to liší od normálního CGI? Pustit něco jako samostatný proces je CGI. Pustit něco pod uživatelem umí suexec. Jestli je na začátku spouštěného #!/usr/bin/php nebo #!/usr/bin/perl nebo dokonce \x7fELF je už pak dost jedno.

[VSi]

Výhoda mod_fcgid oproti prostému CGI je, že pro každý HTTP požadavek se nespouští nový proces, což je pomalé (inicializace Perlu, "kompilace" apod.). Třeba v případě PHP je výkonnostní rozdíl CGI/FastCGI velmi výrazný - u složitějších webů je znát rozdíl i z uživatelského pohledu při načítání stránky v prohlížeči.

FastCGI tedy 1 spuštěný proces využije pro více příchozích požadavků, což ovšem musí ten proces (tj. Perl / PHP / ...) nějakým způsobem podporovat. A tato podpora zřejmě není v Perlu "out-of-the-box" a pak vám mod_fcgid vypisuje ty chyby. Perl pravděpodobně je možné provozovat pod mod_fcgid, ale bude to vyžadovat trochu upravit ty skripty.

Pokud příliš nejde o výkonnost, použil bych prostě obyčejné CGI + Suexec, což by mělo fungovat zcela bez problémů. Další možností by mohl být mod_perl v kompinaci a apache-mpm-itk, který umožňuje, aby Apache procesy pro jednotlivé virtual servery běžely pod definovaným uživatelem.

[Jakub Lucký]

Hm... O apache-mpm-itk jsem také uvažoval, ale má celkem rozporuplné hodnocení výkonnosti (někde výrazně vyšší, jinde naopak...)

O výkonnost jde, je to přeci jen produkční server, úprava skriptů asi nebude problém (zatím nejsou žádné napsané...)

[VSi]

Mpm-itk vyzkoušený nemám, potřeboval jsem vyřešit jen běh PHP, a tam je FastCGI asi nejlepší možnost a informace o mpm-itk mi také přišly všelijaké. Jen mi vadí, že SuexecUserGroup jde nastavovat jen ve <VirtualHost> sekci, a ne třeba v <Directory>, jako to jde u suPHP. Existuje na to sice jednoduchý patch, ale používaní vlastní verze komplikuje správu systému.

Pokud jde o Perl a FastCGI, podívejte se a zkuste třeba modul CGI::Fast.

[Jakub Lucký]

Pro zajímavost (především pro náhodného googlícího čtenáře) přináším benchmark, který jsem našel při hledání

To benchmark mpm-peruser, I used Apache's ab benchmark to load a simple phpinfo() page 1,000 times. I ran the benchmark five times, and averaged the results.

mpm-prefork: average of 6.51 second mpm-itk: average of 37.01 seconds mpm-peruser: average of 6.95 seconds suphp: average of 164.677 seconds suexec: average of 127.219 seconds suexec + bash script: average of 134.836 seconds mod_php: average of 3.753 seconds

zdroj

[VSi]

Škoda, že tam není srovnání s mod_fcgid. Záleží na typu testu (1000 × phpinfo není podle mě zrovna vypovídající vzhledem k reálné zátěži), ale php+fastcgi+suexec vychází srovnatelně s mod_php, nebo i lépe.

Nelze srovnávat mod_php s CGI (ať už se suexec nebo se suphp). Tam je jasné, že CGI bude řádově pomalejší.

[Jakub Lucký]

Přílohy:

• suphp (1036 bytů)
• fcgid (1052 bytů)
• mpm-itk (1074 bytů)
• mod_php (1032 bytů)

Tak jsem dnes testoval, jak jsou na tom jednotlivé PHP suid aplikace...

Testovací skript: Zend bench

Použitý stroj: 2xIntel(R) Xeon(TM) CPU 2.80GHz (dvě jádra), 2GB RAM

Použitý testovací command: ab -n 100 -c 5 http://www.domain.tld/bench.php

Stručné výsledky:

mod_suphp:

Requests per second: 0.16 [#/sec] (mean)

Time per request: 30944.930 [ms] (mean)

Time per request: 6188.986 [ms] (mean, across all concurrent requests)

php-cgi přes fcgid (bash skript wrapper) + suexec

Requests per second: 0.16 [#/sec] (mean)

Time per request: 30634.256 [ms] (mean)

Time per request: 6126.851 [ms] (mean, across all concurrent requests)

mod_php s apache2-mpm-itk

Requests per second: 0.14 [#/sec] (mean)

Time per request: 34676.048 [ms] (mean)

Time per request: 6935.210 [ms] (mean, across all concurrent requests)

A pro zajímavost klasický mod_php bez zabezpečení

Requests per second: 111.82 [#/sec] (mean)

Time per request: 44.713 [ms] (mean)

Time per request: 8.943 [ms] (mean, across all concurrent requests)

########################

Výsledky jsou poměrně tristní, je vidět, že za bezpečnost se platí hodně vysoká cena... V přílohách jsou kompletní výstupy z AB

[VSi]

Nechci se pouštět do nějkých debat, ale měl bych pár (snad užitečných) poznámek:

- Zend bench bych rozhodně nepovažoval za nástroj vhodný k tomuto druhu testování. Co jsem si všimnul, tak 1 spuštění bench.php běží velmi dlouho (jednotky sekund), rozhodně řádově délé než skripty, které vám budou generovat reálnou zátěž. V praxi skripty běží tak 100 - 500 ms, někdy i déle, ale pak už to uživatel "cítí", že je to pomalé. Využití Zend bench bych viděl spíš pro srovnání výkonu různých verzí PHP.

- Vzhledem k předchozímu bodu se mi nezdá, že by mod_php mohl přinést takový výkonostní náskok (o tři řády!) - viz moje testy níže. Rozdíl mezi mod_php/CGI/... se z principu nejvíce projeví na hromadě krátkých požadavků, kdy hraje roli režije spuštění nového procesu.

- V reálné zátěži na serveru s cca 30 požadavky/s na PHP skripty je přínos FastCGI oproti normálnímu CGI (popř. se suPHP) velmi znát. Rozdíl FastCGI vs. mod_php je neznatelný. Mpm-itk jsem netestoval, FastCGI+Suexec pro PHP 100% vyhovuje.

* Moje testy s bench.php *

ab -n 100 -c 5 http://ip/bench.php

== FASTCGI + Suexec ==

Requests per second:    0.21 [#/sec] (mean)
Time per request:       23316.264 [ms] (mean)
Time per request:       4663.253 [ms] (mean, across all concurrent requests)

== MOD_PHP ==

Requests per second:    0.22 [#/sec] (mean)
Time per request:       23132.956 [ms] (mean)
Time per request:       4626.591 [ms] (mean, across all concurrent requests)

Jak je vidět, je to v mém případě úplně stejné. Prosté CGI jsem netestoval, očekával bych , že to bude jen o málo horší.

* Moje testy s reálnou aplikací *

Aplikace: titulní stránka portálu v PHP + PostgreSQL, provoz aplikace na běžném sdíleném hostingu byl nesnesitelně pomalý

ab -n 300 -c 10 http://ip/

== PLAIN CGI + Suexec ==

Requests per second:    6.40 [#/sec] (mean)
Time per request:       1562.403 [ms] (mean)
Time per request:       156.240 [ms] (mean, across all concurrent requests)

== FASTCGI + Suexec ==

Requests per second:    13.33 [#/sec] (mean)
Time per request:       749.939 [ms] (mean)
Time per request:       74.994 [ms] (mean, across all concurrent requests)

= MOD_PHP ==

Requests per second:    13.06 [#/sec] (mean)
Time per request:       765.649 [ms] (mean)
Time per request:       76.565 [ms] (mean, across all concurrent requests)

U této zátěže je vidět, že prosté CGI má výkonnostní propad cca 50% oproti FastCGI či mod_php, které vycházení stejně.

(Testoval jsem na: Debian Lenny, XenServer PV, 2 jádra z Xeonu 2.4GHz, 512MB RAM - během testu trvale volných 300MB)

[Jakub Lucký]

Souhlasím, že Zend benchmark není to nejlepší na testování, ale přišlo mi to šikovnější než obvykle používané phpinfo()

u toho fastcgi+suexec je zvláštní, že výsledky jsou tak rozdílné... Používáte bash wrapper?

[VSi]

Bash wrapper používám, ono to ani jinak asi nejde - suexec požaduje, aby spouštěný soubor měl UID/GID totožné s tím, pod kterým poběží. Tj. nejde spouštět přímo /usr/bin/php-cgi. Stejně v tom bash skriptu jde nastavit plno užitečných věcí - cestu k php.ini, který se má použít; ulimit; nice; proměnné jako PHP_FCGI_CHILDREN - i když se spíš doporučuje nechat správu procesů plně na mod_fcgid a nenechávat PHP spouštět další podprocesy

u toho fastcgi+suexec je zvláštní, že výsledky jsou tak rozdílné...

Teď jsem se nějak ztratil. Proti čemu jsou rozdílné?

[Jakub Lucký]

U vás není u Zend Bench skoro žádný rozdíl mezi fcgid a mod_php, u mě je ohromný... A nechápu proč (a rád bych to vyřešil, protože pak by mi to umožnilo používat suexec všude)

[VSi]

Skoro to vypadá, jako by u vás ten Zend Bench pod mod_php skončil okamžitě s nějakou chybou - tj. provede se hodně rychle. Co se stane, když si bench.php otevřete normálně v prohlížeči a server je nastaven na mod_php? U mě načtení trvá několik vteřin a zatížení CPU je 100%.

Jestliže jsou v tom bench.php nějaké na CPU náročné výpočty, které trvají normálně několik vteřin, a vy máte u mod_php:

Time per request: 8.943 [ms]

tak je to nějaké divné.

[Jakub Lucký]

Problém tam asi byl, dneska jsem s tím serverem trochu šachoval... Tady jsou skutečné výsledky s mod_php

Requests per second: 0.15 [#/sec] (mean)

Time per request: 34107.600 [ms] (mean)

Time per request: 6821.520 [ms] (mean, across all concurrent requests)

[pht]

Nebo mod_selinux. Ten pro každý request pustí vlákno, kterému omezí práva na to co chcete. Je to rychlé a bezpečné zároveň.

[VSi]

Osobně mám rozjeto "fastcgi+suexec+php". Vše šlape tak jak má a ta koncepce řešení by měla být podle mne univerzáslní a fungovat i na perl. V týdnu to otestuji ve virtuální mašině a kdyžtak nasadím na ostrý provoz. Osobně bych v tom ale problém neviděl.
Jediným problémem, jak už bylo řečeno, je suexec, který jede natvrdo z /var/www :-/. Rekompilace apache a úprava zdrojáků je jednoduchá věc, ale mnohem jednoduší je bind adresářů a člověk se pak nemusí starat o aktualizace. Musí se pak sice překopat celé nastavení apache, ale co se dá dělat, nu.
Zdar Max

[Jakub Lucký]

No, on je trošku problém některé věci našroubovat do stávajícího konceptu... Ale podle toho benchmarku, co jsem uvedl, se vyplatí holt ten mpm-itk, díky kterému se dá navíc suidově udělat cokoliv (mod_perl, mod_python a jiné opičárny)...