Jakie uprawnienia / prawa własności ustawić w folderze sesji PHP podczas uruchamiania FastCGI / PHP-FPM (jako użytkownik „nobody”)?

17

Mam problem z uruchomieniem wielu skryptów, ponieważ PHP-FPM nie może pisać do mojego folderu sesji:

„2009/10/01 23:54:07 [błąd] 17830 # 0: * 24 FastCGI wysłany w stderr:„ Ostrzeżenie PHP:
    Nieznany: open (/ var / lib / php / session / sess_cskfq4godj4ka2a637i5lq41o5, O_RDWR)
    nie powiodło się: Odmowa zezwolenia (13) w Nieznany w wierszu 0
Ostrzeżenie PHP: Nieznany: Nie można zapisać danych sesji (plików). Proszę zweryfikuj
    że bieżące ustawienie session.save_path jest poprawne
    (/ var / lib / php / session) w Nieznany w wierszu 0 „podczas czytania w górę”

Oczywiście jest to kwestia pozwolenia; właścicielem / grupą mojego folderu sesji jest użytkownik serwera WWW, NGINX. PHP-FPM działa tak, nobodyjakby i dlatego dodanie go do grupy nginx nie jest takie proste.

Tymczasowym rozwiązaniem jest ustawienie uprawnień /var/lib/php/sessiondo 777- mam wrażenie, że nie jest to „najlepsza praktyka”.

Jaka jest najlepsza praktyka, gdy trzeba przypisać demonowi dostęp do zapisu do folderu, ale działa on jako nobody?

— Profesor Frink
źródło

24

Właściwe uprawnienia dla nas gdzie

chown -R nobody:nogroup /var/lib/php/session

jak php-cgibiegnie jak nobody, choć nginx działa jako użytkowniknginx

— Warkotać
źródło

W moim przypadku nie była to kwestia własności / uprawnień. Usuń „3;” from session.save_path = "3; / var / lib / php / session"

— John Doe

1

Pojawia się następujący błąd: Niepoprawna grupa << nikt: nogroup >> :(

— Pathros

mogłem zobaczyć, który jest moim nobodyużytkownikiem, który uruchamia php z tym wierszem kodu: <?php echo exec('whoami'); ?>(w moim przypadku www-data), a potem było to proste, ponieważ właśnie napisałem, chown -R www-data:www-data /var/lib/php/sessionsże jest to niedoceniany wynik google, ponieważ była to jedyna odpowiedź, która pomogła ja po godzinach poszukiwań! dzięki!

— Dimitar

9

Jeśli używasz nginx, możesz napotkać to podczas uruchamiania aktualizacji systemu.

Czasami podczas aktualizacji systemu grupa /var/lib/php/sessionzmienia się na apache.

Spróbuj wykonać sudo chgrp nginx /var/lib/php/*zamiast ustawiać uprawnienia na 777, co jest złą praktyką.

To mi przynajmniej działało.

— Nick G.
źródło

1

To powinno być oznaczone jako zaakceptowana odpowiedź.

— Yuda Prawira

3

Użyj dyrektywy /etc/php.ini session.save_path .

Tymczasowym rozwiązaniem jest ustawienie uprawnień / var / lib / php / session na 777 - mam wrażenie, że nie jest to „najlepsza praktyka”.

„Jeśli pozostawisz ten zestaw w katalogu czytelnym dla całego świata, inni użytkownicy na serwerze mogą przechwycić sesje, uzyskując listę plików w tym katalogu”.

— SaveTheRbtz
źródło

Przepraszam, myślę, że nie byłem pewien: session.save_path jest już ustawiony na / var / lib / php / session. Problem polega na tym, że nie jestem w stanie ustalić, jakie uprawnienia i prawa własności przypisać do katalogu ścieżki sesji, aby zarówno PHP-FPM mógł do niego pisać, jak i zapewnić mu bezpieczeństwo. Ustawienie katalogu jako właściciela / grupy „nginx” (serwer sieciowy, na którym pracuję) i uprawnień 755 nie wydaje się załatwić

— profesor Frink

4

1. Użyj tego samego użytkownika: group dla nginx i php-fpm (przez jeden nginx.conflub php-fpm.conf), abyś mógł zachować ten katalog 700. 2. Użyj, chown -R nginx:nobody /var/lib/php/session && chmod -R 770 /var/lib/php/sessionwięc myślę, że zarówno nginx, jak i php-fpm mogą go używać

— SaveTheRbtz

2

Mogę potwierdzić, że użycie nginx: nobody (lub nginx: nogroup w niektórych okolicznościach) działa. Jeśli to możliwe, skłaniam się ku opcji 1 SaveTheRbtz.

— Michael Johnson,

3

Musiałem utworzyć folder z uprawnieniami 0700 w / var / lib / php / session dla każdej puli php-fpm.

Właścicielem tego folderu jest użytkownik i grupa z puli php-fpm.

I / var / lib / php / session teraz 0777.

Myślę, że ta metoda jest najbezpieczniejsza. Tylko użytkownik puli php-fpm będzie widział te sesje.

— Alexander Merkulov
źródło

1

Miałem ten sam problem i go rozwiązałem. Poszedłem do /tmp(tam są moje pliki ses_ *) i usunąłem je wszystkie. Potem wszystko było w porządku.

Tak blisko, jak mogłem stwierdzić, system próbował pisać na starych zablokowanych plikach.

Problem pojawił się po tym, jak się bawiłem php.ini. Straciłem kilka lat życia, ale w końcu znalazłem rozwiązanie.

— Christos
źródło

1

Prawidłowym sposobem powinna być zmiana własności folderu sesji na nginx. Jednak PHP-FPM nie działa domyślnie przy użyciu użytkownika nginx. Domyślnie używa apache.

Powiedziawszy to, musisz zmienić użytkownika używanego przez PHP-FPM poprzez edycję /etc/php-fpm.d/www.conf.

; Unix user/group of processes
; Note: The user is mandatory. If the group is not set, the default user's group
;       will be used.
; RPM: apache Choosed to be able to access some dir as httpd
user = nginx
; RPM: Keep a group allowed to write in log dir.
group = nginx

Uruchom ponownie PHP-FPM i powinieneś być gotowy.

service php-fpm restart

PHP lokalizacja ścieżka sesji można znaleźć w /etc/php.ininiedostatecznie session.save_path. /var/lib/php/sessionjest wartością domyślną.

Polecenie aktualizacji własności i grupy folderów sesji php

chown -R nginx:nginx /var/lib/php/session

I powinieneś być dobry nawet z chmod 700.

— josephting
źródło

1

Sesje na katalog / var / lib / php / powinny mieć lepkie uprawnienia do bitów.

sudo chmod 1773 /var/lib/php/sessions

ls -al /var/lib/php/
drwxr-xr-x  4 root root   .
drwxr-xr-x 51 root root   ..
drwxr-xr-x  3 root root   modules
drwx-wx-wt  2 root root   sessions

— Łukasz
źródło

0

Oparte na odpowiedzi @Judder , aby zadziałało, musiałem dodać następujące polecenie, aby dać uprawnienia do odczytu i zapisu nikomu i nogroup :

chown -R nobody:nogroup /var/lib/php/session

sudo chmod -R ug+rw /var/lib/php/sessions

chmod zmieni uprawnienia w danym folderze
-R zastosuje te same uprawnienia do utworzonych folderów i plików w danym folderze
u dla użytkownika
g dla grupy
r dla uprawnienia do odczytu
w dla uprawnienia do zapisu

— Guillaume Genreau
źródło