Problemy z PHP 5.3 i folderem sesji

81

Niedawno zaktualizowałem do PHP 5.3 i od tego czasu otrzymuję (sporadyczne) komunikaty o błędach, które wskazują, że Apache (lub może być czystszym z plików sesji) nie ma uprawnień do folderu, w którym przechowywane są sesje.
Dzieje się to losowo i nie można go odtworzyć z dokładnymi krokami, co doprowadziło mnie do wniosku, że jest to czystsze sesje.
Czy ktoś ma jakieś doświadczenie z takimi błędami?

Komunikat o błędzie (który jest uruchamiany w session_start()linii) to:

ps_files_cleanup_dir: opendir (/ var / lib / php5) failed: Odmowa uprawnień.

ls -ltr w katalogu sesji daje:

drwx-wx-wt  2 root          root          4096 2010-05-25 12:39 php5

W tym katalogu widzę pliki sesji należące do www-data, czyli mojego Apache, a aplikacja działa dobrze. Co sprawia, że zastanawiam się, pod jakim użytkownikiem działa sesja GC?

php session

— Itay Moav -Malimovka
źródło

Zrobiłem, ale nie w 5.3. Okazało się, że był to błąd uprawnień, który przefiltrował do ścieżki zapisu sesji. Zakładam, że sprawdziłeś uprawnienia?

— Jarrod Nettles

@Jarrod Widzę, że dane www mogą czytać i zapisywać w tym folderze (który ma teraz w & r dla każdego, użytkownika, grupy i świata). Czy powinienem sprawdzić coś innego?

— Itay Moav -Malimovka

Domyślam się, że powodem, dla którego zdarza się to sporadycznie, jest to, że błąd występuje, gdy uruchomiony jest moduł odśmiecania sesji, który, jak sądzę, ma domyślnie 1% szansy uruchomienia na inicjalizację sesji. Czy wprowadziłeś jakieś zmiany w php.ini dotyczące sesji? Co jest poza wartością domyślną? Sprawdź właściciela folderu sesji, po czym nie widzę pliku .ini ani błędów.

— Jarrod Nettles

Właścicielem jest root, sesje są tworzone przez www-data, każdy ma dostęp do tego folderu. Przejdę kolejno po ustawieniach ini, poszukam czegoś podejrzanego.

— Itay Moav -Malimovka

ps_files_cleanup_dir: opendir (/ var / lib / php5) failed: Permission denied (

— Itay Moav -Malimovka

121

Poprawka: w Twoim php.inizestawie session.gc_probabilitydo0

Przyczyna, jak sądzę, znalazłem tutaj http://somethingemporium.com/2007/06/obscure-error-with-php5-on-debian-ubuntu-session-phpini-garbage

Zasadniczo, czyszczenie pamięci jest skonfigurowane do wykonywania zadań cron w niektórych systemach (np. Ubuntu / Debian). Niektóre pliki wykonywalne php ini, takie jak php-cli, również próbują usuwać elementy bezużyteczne, co skutkuje wyświetlanym błędem.

— Diwant Vaidya
źródło

6

Ten problem występuje również w systemie Ubuntu 10.04, ale po sprawdzeniu pliku php.ini, który znalazłem, jest session.gc_probabilityjuż ustawiony 0.

— Jonathan,

5

@Jonathan - Prawdopodobnie zauważysz, że Twoja aplikacja ustawia wtedy wartość.

— SynackSA,

3

@SynackSA Co dziwne, to kiedy utworzyć niestandardowy, Miejsce konkretny plik php.ini, to gdy session.gc_probabilitywyzwalacze do 1. To zdarzyło się nawet, gdy nie ma żadnych ustawień w pliku php.ini w ogóle ! Używam Suphp na Ubuntu, Apache 2.2. Zastanawiam się, czy to jakiś błąd. W każdym razie dodanie session.gc_probability = 0do mojego niestandardowego, specyficznego dla witryny pliku php.ini wydaje się rozwiązać problem.

— Jonathan,

2

@Jonathan Tak to powinno działać, ponieważ domyślna wartość to 1

— ROunofF

2

To wyłącza czyszczenie pamięci sesji. Prawdopodobnie powinieneś chcieć sprawdzić, czy rzeczywiście istnieje cron czyszczący twoje sesje.

— hansgoed

23

Wydaje się, że jest to typowy błąd na serwerach Ubuntu (używam Lucid LTS). Są tam domyślne uprawnienia katalogu / var / lib / php5

drwx-wx-wt  2 root     root     4096 2011-11-04 02:09 php5

więc można go zapisać, ale nie odczytać przez serwer WWW, myślę, że to wyjaśnia błędy.

Ponieważ Ubuntu ma własne czyszczenie śmieci za pomocą cron ( /etc/cron.d/php5), prawdopodobnie najlepiej jest wyłączyć wyrzucanie śmieci w php, jak zasugerował powyżej Diwant Vaidya.

session.gc_probability = 0

W rzeczywistości istnieje powód, dla którego folder sesji nie powinien być czytelny dla świata - jak mówi Podręcznik PHP :

Jeśli pozostawisz to ustawienie w katalogu do odczytu dla wszystkich użytkowników, takim jak / tmp (ustawienie domyślne), inni użytkownicy na serwerze mogą być w stanie przejąć sesje, pobierając listę plików w tym katalogu.

— Marie Fischer
źródło

2

Rozwiązaniem, którego obecnie używam (które nie jestem pewien, jest właściwe), jest przekazanie prawa własności do folderu sesji użytkownikowi Apache (w moim przypadku dane www).

— Itay Moav -Malimovka
źródło

2

Jak Marie wspomina powyżej, może to spowodować problem z bezpieczeństwem na dowolnym serwerze produkcyjnym.

— Kzqai,

2

Już dawno

— wdrożyłem

1

@pike Czyszczenie sesji jest obsługiwane przez php cli przez CRON

— Itay Moav -Malimovka

1

Ten problem niepokoi mnie od jakiegoś czasu. Zmieniłem wartość zgodnie z sugestią w php.ini i problem nadal występował. Znalazłem tę samą wartość konfiguracyjną w moim index.php, a także private / Zend / session.php. Warto więc przyjrzeć się nieco głębiej, jeśli problem nadal występuje. Mam nadzieję, że komuś się to przyda.

— ChrisFNZ
źródło