php - disable_functions

[Gość Fo]

Witam,

 

krótkie i szybkie pytanko, a wcześniej przedstawienie sytuacji.

 

Posiadam powiedzmy 20 kont, które pracują na php,

php4 ma domyślnie wyłączone poprzez disable_functions następujące funkcje:

system, exec, shell_exec, passthru, escapeshellcmd, escapeshellarg, glob, open

 

a teraz trochę zagadka (zaraz powiem czemu trochę ) - jak włączyć np. komende system dla określonego 1 konta ?

 

teraz rozwinięcie na temat "trochę zagadka"

wiadomo, powinienem posłużyć się w celu włączenia powiedzmy system dyrektywą: php_admin_value disable_functions "shell_exec, passthru, escapeshellcmd......" w konfiguracji danego virtualhosta tj:

<VirtualHost IP:80>

DocumentRoot /home/www/konto_z_php_system

php_admin_value disable_functions "shell_exec, passthru, escapeshellcmd.... (i reszta oprócz system)"

</VirtualHost>

i tak też zrobiłem, phpinfo w katalogu tego konta mówi iż:

master value (wartości ustawione w php.ini) zawiera dla disable_functions wszystkie parametry które wyłączyłem (od system po open) a local value zawiera wszystkie parametry które wyłączyłem oprócz system - które mnie interesuje - czyli które ma być włączone.

 

no i teraz tylko taki gryps że to niestety mimo wszystko nie działa

 

byłbym wdzięczny za wszelkie rady,

php4 na moim serwerze jest w wersji 4.3.11

 

+ czy ktoś wie może w jaki sposób określić w konfiguracji apache ścieżkę do osobnego php.ini dla konkretnego konta - ew. dir'a ?

czyli żeby domyślne php.ini odczytywane było z miejsca które określiło się podczas kompilacji php4 a to niestandardowe z miejsca które wskaże w konfiguracji httpd.

coś kiedyś chyba było takiego jak php_ini_set_dir - ale nie mogę się tego za chiny doszukać.

 

pozdrawiam,

Artur Kwiatkowsk alias Fo

[Gość patrick]

+ czy ktoś wie może w jaki sposób określić w konfiguracji apache ścieżkę do osobnego php.ini dla konkretnego konta - ew. dir'a ?

 

czy to nie to PHPINIDir ?

To wchodzi w sklad modulu sapi_apache*

I chyba o to ci chodzi ..

[Gość Fo]

@patrick - tia, to o to chodzi, ale hmm, PHPINIDir ustawione w konfiguracji konkretnego virtualhosta (jednego!) działa... ale równocześnie ten dir dla php.ini obowiązuje dla całej reszty virtualhostów kiedy ja chce jedynie aby obowiązywał dla tego jednego do którego to dopisałem.

 

dodatkowo apacz krzyczy iż PHPINIDIR może być nastawione tylko raz w całym httpd.conf w momencie kiedy próbóję ustawić jeszcze gdzieś tę dyrektywę...

 

jakieś rady ?

 

pozdrawiam,

Fo

[Jarosław Szmańda 42]

Może będę górnikiem ale mam pytanie, a nie chciał bym zakładać kolejnego tematu.

 

Co warto zablokować w disable_functions? Obecnie nie mam tam nic, a to chyba źle, prawda?

 

Pzdr!

[Gość patrick]

Może byś zaczął szukać ? czytać ? Ale prościej pisze się posty nie ?

google & http://pl.php.net/manual/pl/index.php

[lukaschemp 27]

Używasz może suPHP?

[Jarosław Szmańda 42]

Z tego co wiem to nie.

[beliq 442]

mod_php to zło, przejdź na fastCGI, a i wtedy disabled_functions przestaje mieć większe znaczenie tak naprawdę,

bo ładnie możesz konta polimitować per UID z poziomu systemu...

Oczywiście to wszystko pod warunkiem, że to nie jest hosting dzielony, bo wtedy

Bóg tylko jeden wie co można, a czego nie wyłaczać, tak by klienci się co 5 minut nie skarżyli,

że im jakiś tam supa dupa pro CMS nie działa.

 

Ogólnie idea tych wszystkich zabezpieczeń typu disabled_functions, safe_mode, jest taka,

że trzeba użytkownikow odebrać część udogodnień z racji tego, iż wszystkie witryny są

obsługiwane z uprawnieniami użytkownika Apache,

stąd udostępnienie zbyt rozbudowanej funkcjonalności może doprowadzić do eskalacji

problemów związanych z bezpieczeństwem i stabilnością platformy.

[Jarosław Szmańda 42]

Hmm czyli wywalić php5 na rzecz fastcgi? A jak to się ma do funkcjonalności i wydajności? Bo np. ten lighttpd ma mniej funkcji niż apace2 -taki przykład tylko

 

Ale już o tym czytam.

[beliq 442]

Przecież Apache obsługuje fastCGI bardzo łanie.

Wcale go nie trzeba niczym zastępować.

Inna sprawa, że na dzień dzisiejszy lighty nie obsługuje czegoś takiego jak suexec,

stąd przy środowiskach wieloużytkownikowych nie będziesz mógł zmieniać UID'a

dla procesów PHP, a co powoduje powrót do punktu wyjścia...

[Jarosław Szmańda 42]

Za dużych wymagań to ja nie mam

http://packages.debian.org/etch/libapache2-mod-fastcgi chodzi o ten moduł, prawda? Postaram się go przetestować dzisiaj, jak tylko VPSRepublic się odwiesi...

[Gość patrick]

tak o ten.

[malu 460]

Bell - skoro zagłębiasz się w sposób działania FCGI, a raczej korzyści jakie z tego płyną. Jednak mógłbyś mu wytłumaczyć na jakiej zasadzie to działa

Bo jak przeczytałem

Hmm czyli wywalić php5 na rzecz fastcgi? A jak to się ma do funkcjonalności i wydajności? Bo np. ten lighttpd ma mniej funkcji niż apace2 -taki przykład tylko smile.gif

to wygląda to jakoby JarekMK myślał, że FCGI nie jest sposobem działania PHP tylko jest to takie "PHP zamiast mod_PHP". Ogólnie ja bym sobie oszczędził takich prawideł Bell bo może to być źle odczytane, a dlaczego to już pewnie sam dobrze wiesz.

Dobra żeby jakoś ładnie zakończyć ten temat dodam jeszcze coś od siebie dotyczącego bezpieczeństwa/niebezpieczeństwa PHP.

Niebezpieczeństwem php działającego w mod_php jest działanie z GID oraz UID samego serwera http - o czym wspomniał już bellerofont. Można temu zapobiec uruchamiając php w CGI lub FCGI -> jednak sprowadza się to do tego samego jeżeli nie jest na to nałożony jakiś wrapper odpowiednio suPHP lub suEXEC - o czym zapomniał napomnieć Marcin. Powinno się postawić sobie minimum 2 główne pytania.

1) Zależy mi na wydajności czy bezpieczeństwie?

2) Chciałbym zabezpieczyć PHP z poziomu samego PHP czy systemu?

Gdy już poznamy swoje zamiary - odpowiednio dobierzemy sobie potrzebne oprogramowanie po dokładnym przestudiowaniu możliwości CGI/FCGI oraz suPHP/suEXEC.

 

PS. Nie można oczywiście zapomnieć o tym, że można zabezpieczyć PHP obydwoma sposobami "na raz". Wprowadzając indywidualne php.ini dla każdego użytkownika przy użyciu wrappera php. Będziemy wtedy mogli blokować indywidualnie niebezpieczne funkcje php, oraz środowisko działania php będzie ograniczone dla UID użytkownika.

[beliq 442]

Przecież narzut fastCGI wcale nie jest taki duży - ot czasem doforkować trochę procesów()...

[ertcap 0]

Przecież narzut fastCGI wcale nie jest taki duży - ot czasem doforkować trochę procesów()...

A to zalezy - czasami potrafi mocniej dociazyc - w przypadku mod_php martwimy sie ogolnie wydajnoscia skryptow, w przypadku fcgi dochodzi jeszcze kwestia odpalania ilosci skryptow na wywolanie strony ("modelowy" przyklad - strona www z 50 obrazkami, kazdy obrazek jest generowany przez phpa w locie...)

[Prohost 345]

Zabezpiecza się "systemowo" bo np. wyłączysz funkcje w php a w cgi można zrobić co się chce i co? Podstawą jest odpalanie wszystkiego co się da na prawach użytkownika danego i odpowiednie prawa dostępu.