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?

linux security php centos Profesor Frink
źródło

Odpowiedzi:

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