O

pcja open_basedir ogranicza listę plików, które mogą zostać odtworzone przez interpreter PHP do określonego drzewa katalogów. Kiedy skrypt próbuje otworzyć plik za pomocą np. funkcji fopen() lub gzopen() najpierw sprawdzana jest lokalizacja tego pliku. W przypadku, gdy plik jest poza zdefiniowanym drzewem katalogów, PHP odmówi jego odtworzenia (Warning: open_basedir restriction in effect).

Tyczy się to również wszystkich linków symbolicznych. Wartością specjalną tej opcji jest “.” (kropka), która oznacza aktualny, roboczy katalog skryptu. Należy jednak unikać tego ustawienia, ze względu na możliwość zmiany tego katalogu za pomocą funkcji chdir(). Pod systemem Windows, dopuszczalne drzewa katalogów powinny być oddzielane za pomocą średnika; w innych systemach jest to znak dwukropka:. Jeśli PHP uruchomione jest jako moduł dla Apache – ścieżki z nadrzędnych katalogów są automatycznie dziedziczone.

Restrykcje określone w opcji open_basedir są nazwami katalogów od wersji PHP 5.2.16 oraz 5.3.4. We wcześniejszych wersjach były to tylko prefiksy. Oznaczało to, że ustawienie:

open_basedir = /var/inc

Zawierał w sobie ścieżki do katalogów /var/include oraz /var/incorporate – jeśli takowe istniały. Jeśli limit miał dotyczyć określonego katalogu ścieżka musiała zostać zakończona znakiem slash / – na przykład /var/inc/. Od wersji PHP 5.3.0 open_basedir może zostać rozszerzane podczas wykonywania skryptu. Oznacza to, że jeśli w pliku konfiguracyjnym php.ini open_basedir zostanie ustawione na wartość /www/ – to skrypt może naciągnąć to ustawienie za pomocą funkcji ini_set() do wartości /www/tmp/. Istnieje również możliwość ustawienia różnych wartości dla każdego wirtualnego hosta z osobna – za pomocą dyrektywy php_admin_value:

php_admin_flag engine on
php_admin_value open_basedir "/var/include:/tmp"
php_admin_value upload_tmp_dir "/tmp"

Mimo ograniczeń jakie prowadza ta opcja – nie należy traktować jej jako jeden z głównych filaru bezpieczeństwa PHP, którym powinien być przemyślany kod. W swojej historii PHP kilka luk tyczyło się możliwości obejścia tego mechanizmu. Mimo to potrafi ona znacznie ograniczyć i utrudnić tzw. File Include Attacks. Luki w bezpieczeństwie aplikacji PHP (i nie tylko) zawsze będą istnieć. Dlatego wzmacnianie ich od strony konfiguracji serwera, nawet w najmniejszym stopniu ma sens. Decydując się na używanie tej opcji – zaleca się również wyłączenie funkcji symlink() (po uprzednim sprawdzeniu, czy żadna aplikacja PHP na serwerze nie korzysta z tej funkcji).

Więcej informacji: Hardened PHP Project