Uprawnienia plików w PrestaShop: Prawidłowa konfiguracja

411 wyświetleń

Zrozumienie uprawnień plików w systemie Linux

Każdy plik i katalog na serwerze Linux ma trzy zestawy uprawnień: jeden dla właściciela (owner), jeden dla grupy (group) i jeden dla pozostałych (others — wszyscy inni). Każdy zestaw kontroluje trzy akcje: odczyt (r), zapis (w) i wykonywanie (x). Uprawnienia te są reprezentowane numerycznie za pomocą notacji ósemkowej (octal), gdzie odczyt równa się 4, zapis równa się 2, a wykonywanie równa się 1. Wartości są sumowane dla każdego zestawu, tworząc trzycyfrową liczbę, taką jak 755 lub 644.

Na przykład uprawnienie 755 oznacza, że właściciel może czytać, zapisywać i wykonywać (7 = 4+2+1), podczas gdy grupa i pozostali mogą tylko czytać i wykonywać (5 = 4+0+1). Uprawnienie 644 oznacza, że właściciel może czytać i zapisywać (6 = 4+2+0), podczas gdy grupa i pozostali mogą tylko czytać (4 = 4+0+0). Zrozumienie tego systemu jest fundamentalne dla prowadzenia bezpiecznego i funkcjonalnego sklepu PrestaShop.

Oprócz numerycznych uprawnień, każdy plik ma przypisanego właściciela i grupę. Na serwerze WWW proces serwera (Apache lub Nginx) działa jako konkretny użytkownik, zazwyczaj www-data na Debian/Ubuntu lub apache/nobody na CentOS/RHEL. Serwer WWW musi mieć możliwość odczytu Twoich plików PrestaShop, aby je serwować, oraz potrzebuje dostępu do zapisu w określonych katalogach na potrzeby przesyłania plików, cachowania i konfiguracji.

Prawidłowe uprawnienia dla katalogów i plików PrestaShop

Ogólna zasada dla PrestaShop jest prosta: katalogi powinny mieć uprawnienia 755, a pliki powinny mieć uprawnienia 644. Daje to właścicielowi pełną kontrolę, podczas gdy grupa i pozostali mogą czytać (oraz wykonywać/przechodzić w przypadku katalogów), ale nie mogą niczego modyfikować. Użytkownik serwera WWW powinien być właścicielem wszystkich plików PrestaShop lub co najmniej należeć do grupy, która je posiada.

Aby ustawić te uprawnienia w całej instalacji PrestaShop, połącz się z serwerem przez SSH i uruchom:

find /var/www/html/prestashop -type d -exec chmod 755 {} \\;\nfind /var/www/html/prestashop -type f -exec chmod 644 {} \\;

Zastąp /var/www/html/prestashop rzeczywistą ścieżką do Twojej instalacji PrestaShop. Pierwsze polecenie znajduje wszystkie katalogi i ustawia im uprawnienia 755. Drugie znajduje wszystkie pliki i ustawia im uprawnienia 644.

Jednakże pewne katalogi wymagają dostępu do zapisu przez serwer WWW. Te katalogi wymagają szczególnej uwagi, ponieważ PrestaShop zapisuje w nich dane podczas normalnej pracy:

  • /var/cache/ — Skompilowane szablony Smarty i cache Symfony
  • /var/logs/ — Pliki logów aplikacji
  • /upload/ — Pliki przesłane przez klientów
  • /download/ — Pliki produktów wirtualnych
  • /img/ — Zdjęcia produktów, kategorii, stron CMS
  • /modules/ — Instalacja i aktualizacje modułów
  • /themes/ — Pliki cache motywu
  • /translations/ — Pliki eksportu tłumaczeń
  • /config/ — Pliki konfiguracyjne (parameters.php)
  • /app/config/ — Konfiguracja Symfony
  • /app/Resources/translations/ — Tłumaczenia Symfony

Jeśli użytkownik serwera WWW jest właścicielem tych plików (co jest zalecaną konfiguracją), to uprawnienia 755/644 są wystarczające. Jeśli serwer WWW działa jako inny użytkownik, może być konieczna zmiana uprawnień grupowych lub właścicielstwa.

Ustawianie prawidłowego właścicielstwa za pomocą chown

Właścicielstwo jest równie ważne jak uprawnienia. Polecenie chown zmienia właściciela i grupę plików. Dla typowego serwera Debian/Ubuntu z Apache lub Nginx, użytkownikiem serwera WWW jest www-data:

sudo chown -R www-data:www-data /var/www/html/prestashop

Flaga -R stosuje zmianę rekurencyjnie do wszystkich plików i podkatalogów. Na systemach CentOS lub RHEL zastąp www-data wartością apache lub nginx w zależności od Twojego serwera WWW.

Powszechnym alternatywnym podejściem jest ustawienie właściciela na Twojego użytkownika SSH/FTP, a grupy na użytkownika serwera WWW. Pozwala to edytować pliki przez FTP lub SSH, jednocześnie umożliwiając serwerowi WWW ich odczyt:

sudo chown -R twojuzytkownik:www-data /var/www/html/prestashop

W takim przypadku katalogi wymagające dostępu do zapisu przez serwer WWW powinny mieć uprawnienia 775 (zapis dla grupy), a pliki do zapisu powinny mieć 664:

find /var/www/html/prestashop/var -type d -exec chmod 775 {} \\;\nfind /var/www/html/prestashop/var -type f -exec chmod 664 {} \\;\nfind /var/www/html/prestashop/img -type d -exec chmod 775 {} \\;\nfind /var/www/html/prestashop/img -type f -exec chmod 664 {} \\;

Hosting współdzielony vs VPS vs serwer dedykowany

Środowisko hostingowe drastycznie wpływa na to, jak uprawnienia plików działają w praktyce. Zrozumienie różnic jest kluczowe dla prawidłowej konfiguracji uprawnień.

Hosting współdzielony (Shared Hosting)

Na hostingu współdzielonym dostęp do plików uzyskujesz zazwyczaj przez FTP lub menedżer plików w cPanelu/Plesku. Model wykonywania PHP różni się w zależności od dostawcy, ale większość nowoczesnych hostów współdzielonych korzysta z PHP-FPM lub suPHP, co oznacza, że PHP działa jako Twoje konto użytkownika, a nie jako globalny użytkownik serwera WWW. To znacząco upraszcza kwestię uprawnień: ponieważ PHP działa jako Twój użytkownik, może już czytać i zapisywać Twoje pliki ze standardowymi uprawnieniami 755/644. Rzadko musisz zmieniać właścicielstwo na hostingu współdzielonym, ponieważ wszystko już należy do Twojego konta.

Jeśli napotkasz błędy uprawnień na hostingu współdzielonym, sprawdź u dostawcy, czy używa suPHP lub PHP-FPM. Jeśli stosuje starszy model mod_php, może być konieczne tymczasowe ustawienie niektórych katalogów na 777 (choć nie jest to zalecane ze względów bezpieczeństwa). Większość renomowanych dostawców odeszła od mod_php właśnie z powodu tych komplikacji z uprawnieniami.

VPS (Virtual Private Server — Wirtualny Serwer Prywatny)

Na VPS masz pełną kontrolę. Jest to najczęstsza konfiguracja dla poważnych sklepów PrestaShop. Powinieneś upewnić się, że użytkownik serwera WWW jest właścicielem plików PrestaShop lub co najmniej należy do grupy mającej dostęp do odczytu. Zalecana konfiguracja to:

  1. Ustaw właściciela na www-data:www-data (lub Twojego użytkownika serwera WWW)
  2. Użyj 755 dla katalogów i 644 dla plików
  3. Używaj SSH z sudo do wprowadzania zmian lub dodaj swojego użytkownika SSH do grupy www-data

Aby dodać swojego użytkownika SSH do grupy serwera WWW:

sudo usermod -a -G www-data twojuzytkownik

Następnie ustaw bit zapisu dla grupy na katalogach, które chcesz edytować:

chmod g+w /var/www/html/prestashop/themes/twoj-motyw/

Serwer dedykowany

Serwery dedykowane działają na tych samych zasadach co konfiguracje VPS. Główna różnica to wydajność: masz więcej zasobów, więc możesz uruchomić PHP-FPM z dedykowanymi pulami na stronę. Każda pula może działać jako inny użytkownik, zapewniając lepszą izolację, jeśli hostujesz wiele sklepów PrestaShop na tym samym serwerze.

Modele wykonywania PHP: suPHP vs mod_php vs PHP-FPM

Sposób, w jaki PHP jest wykonywane na Twoim serwerze, bezpośrednio determinuje, który użytkownik tworzy pliki i tym samym jakie uprawnienia są potrzebne.

mod_php (moduł Apache)

To najstarszy i najprostszy model. PHP działa jako część procesu Apache, co oznacza, że cały kod PHP jest wykonywany jako użytkownik Apache (zazwyczaj www-data lub apache). Problem polega na tym, że pliki tworzone przez PHP (cache, uploady itp.) są własnością użytkownika serwera WWW, a nie Twojego konta. Może to utrudniać zarządzanie przez FTP i stwarza zagrożenia bezpieczeństwa na hostach współdzielonych, ponieważ wszystkie strony działają jako ten sam użytkownik.

Z mod_php pliki PrestaShop powinny być własnością użytkownika Apache, a uprawnienia 755/644 działają prawidłowo. Jednakże ten model jest w dużej mierze przestarzały na nowoczesnych serwerach.

suPHP

suPHP uruchamia PHP jako właściciel pliku, a nie jako użytkownik serwera WWW. Oznacza to, że jeśli Twoje pliki są własnością twojuzytkownik, PHP również działa jako twojuzytkownik. Jest to bezpieczniejsze na hostingu współdzielonym, ponieważ każde konto jest izolowane. Standardowe uprawnienia 755/644 działają idealnie z suPHP, ponieważ proces PHP i właściciel pliku to ten sam użytkownik.

Jedno ważne zastrzeżenie: suPHP faktycznie odrzuca pliki z uprawnieniami 777 lub pliki należące do innych użytkowników. Jeśli ustawisz 777 na serwerze z suPHP, PHP odmówi wykonania tych plików, wyświetlając zamiast tego błąd 500 Internal Server Error.

PHP-FPM (FastCGI Process Manager)

PHP-FPM to nowoczesny standard. Uruchamia PHP jako oddzielny proces od serwera WWW, z konfigurowalnym użytkownikiem i grupą per pula. Na VPS, PHP-FPM zazwyczaj działa jako www-data. Na hostingu współdzielonym z CloudLinux lub podobnym rozwiązaniem, każde konto otrzymuje własną pulę PHP-FPM działającą jako użytkownik tego konta.

PHP-FPM w połączeniu z Nginx to zalecana konfiguracja dla wydajności PrestaShop. Standardowy schemat uprawnień 755/644 sprawdza się dobrze. Upewnij się, że użytkownik puli PHP-FPM odpowiada właścicielowi plików lub ma odpowiedni dostęp grupowy.

Dlaczego uprawnienia 777 są niebezpieczne

Ustawienie uprawnień na 777 oznacza, że każdy użytkownik w systemie może czytać, zapisywać i wykonywać plik. Na hostingu współdzielonym oznacza to, że inne konta na tym samym serwerze mogłyby potencjalnie odczytać Twoje dane logowania do bazy danych z parameters.php lub wstrzyknąć złośliwy kod do Twoich plików PHP.

Nawet na VPS, gdzie jesteś jedynym użytkownikiem, 777 jest niepotrzebne i wskazuje na błędną konfigurację. Jeśli serwer WWW nie może zapisywać w katalogu z uprawnieniami 755, rozwiązaniem jest naprawienie właścicielstwa, a nie otwieranie uprawnień dla całego świata. Oto co powinieneś zrobić zamiast używania 777:

  1. Sprawdź, jako kto działa serwer WWW: ps aux | grep -E \"apache|nginx|httpd\"
  2. Sprawdź właścicielstwo plików: ls -la /var/www/html/prestashop/
  3. Napraw właścicielstwo: sudo chown -R www-data:www-data /sciezka/do/katalogu
  4. Ustaw prawidłowe uprawnienia: chmod 755 /sciezka/do/katalogu

Jeśli znajdziesz poradnik lub post na forum zalecający 777 dla PrestaShop, to przestarzała i niebezpieczna rada. Jedyne uzasadnione zastosowanie 777 dotyczy katalogów /tmp, które mają ustawiony bit sticky (wyświetlany jako 1777), co jest konfiguracją na poziomie systemowym, a nie czymś, co stosuje się do plików PrestaShop.

Kwestie Dockera w kontekście PrestaShop

Uruchamianie PrestaShop w Dockerze wprowadza dodatkową złożoność do uprawnień plików. Wewnątrz kontenera serwer WWW działa jako www-data z konkretnym UID (często 33 na obrazach opartych na Debianie). Na systemie hosta Twój użytkownik ma inny UID. Gdy używasz bind mountów Dockera do montowania plików PrestaShop do kontenera, właścicielstwo plików jest określane przez numeryczny UID, a nie nazwę użytkownika.

Oznacza to, że pliki utworzone na hoście jako Twój użytkownik (np. UID 1000) będą widoczne wewnątrz kontenera jako UID 1000, który nie jest www-data (UID 33). Serwer WWW wewnątrz kontenera może nie być w stanie zapisywać do tych plików.

Rozwiązania problemów z uprawnieniami w Dockerze obejmują:

  • Dopasowanie UID: Stwórz użytkownika wewnątrz kontenera z tym samym UID co Twój użytkownik na hoście lub zmień serwer WWW, aby działał z Twoim UID.
  • Użycie chown w entrypoincie: Dodaj polecenie startowe, które uruchamia chown -R www-data:www-data /var/www/html przy starcie kontenera. Jest to proste, ale może być wolne dla dużych instalacji.
  • Ustawienie uprawnień grupowych: Dodaj swojego użytkownika hosta i www-data do tej samej grupy (po GID), a następnie użyj uprawnień 775/664.
  • Named volumes: Użyj named volumes Dockera zamiast bind mountów. Docker automatycznie zarządza uprawnieniami, ale tracisz bezpośredni dostęp do systemu plików z hosta.

Dla środowisk deweloperskich z bind mountami, najbardziej praktycznym podejściem jest uruchomienie polecenia chown po synchronizacji lub wdrożeniu plików:

docker exec twoj-kontener chown -R www-data:www-data /var/www/html/modules/twoj-modul/

Miej na uwadze, że operacje wewnątrz kontenera (jak instalacja modułu) mogą tworzyć pliki jako www-data, podczas gdy operacje na hoście tworzą pliki jako Twój użytkownik hosta. Ta ciągła niezgodność UID jest najczęstszym źródłem problemów z uprawnieniami w zdockeryzowanych konfiguracjach PrestaShop.

Rozwiązywanie typowych błędów uprawnień

\"Failed to open stream: Permission denied\"

Ten błąd oznacza, że PHP nie może odczytać lub zapisać pliku. Sprawdź właścicielstwo i uprawnienia pliku wskazanego w komunikacie błędu. Najczęstszą przyczyną jest to, że użytkownik serwera WWW nie jest właścicielem pliku lub katalogu. Napraw to za pomocą:

sudo chown www-data:www-data /sciezka/do/pliku\nsudo chmod 644 /sciezka/do/pliku

\"Unable to write to cache directory\"

Silnik szablonów Smarty i framework Symfony w PrestaShop oba zapisują pliki cache. Jeśli katalog var/cache/ nie jest zapisywalny, zobaczysz ten błąd. Katalog cache musi być własnością użytkownika serwera WWW:

sudo chown -R www-data:www-data /var/www/html/prestashop/var/cache/\nsudo chmod -R 755 /var/www/html/prestashop/var/cache/

Po naprawieniu uprawnień wyczyść istniejący cache, usuwając zawartość katalogów cache:

sudo rm -rf /var/www/html/prestashop/var/cache/prod/*\nsudo rm -rf /var/www/html/prestashop/var/cache/dev/*

\"Cannot upload image\" lub \"Cannot install module\"

Przesyłanie obrazów trafia do katalogu img/, a instalacje modułów zapisują do katalogu modules/. Oba muszą być zapisywalne przez użytkownika serwera WWW. Dodatkowo sprawdź, czy ustawienia PHP upload_max_filesize i post_max_size są wystarczająco duże dla Twoich plików, ponieważ mogą one powodować podobnie brzmiące błędy.

sudo chown -R www-data:www-data /var/www/html/prestashop/img/\nsudo chown -R www-data:www-data /var/www/html/prestashop/modules/

\"index.php is not writable\" podczas aktualizacji

Auto-aktualizator PrestaShop potrzebuje dostępu do zapisu praktycznie każdego pliku w instalacji. Przed uruchomieniem aktualizacji ustaw właścicielstwo całej instalacji na użytkownika serwera WWW. Po zakończeniu aktualizacji możesz przywrócić bardziej restrykcyjne właścicielstwo, jeśli chcesz.

Biała strona po zmianie uprawnień

Jeśli widzisz pustą białą stronę po zmianie uprawnień, mogłeś przypadkowo usunąć uprawnienie do wykonywania z katalogów. Katalogi potrzebują bitu wykonywania, aby można je było przeglądać. Katalog z uprawnieniami 644 (bez wykonywania) jest praktycznie niedostępny. Zawsze używaj 755 dla katalogów, nigdy 644.

Możesz również sprawdzić log błędów PHP po więcej szczegółów:

sudo tail -50 /var/log/apache2/error.log\n# lub dla Nginx:\nsudo tail -50 /var/log/nginx/error.log

Uprawnienia resetują się po przesłaniu przez FTP

Niektóre klienty FTP ustawiają własne domyślne uprawnienia podczas przesyłania plików. Sprawdź ustawienia swojego klienta FTP w poszukiwaniu opcji „domyślne uprawnienia" lub „umask". Ustaw tworzenie plików z uprawnieniami 644, a katalogów z 755. Alternatywnie, uruchom polecenia naprawy uprawnień po każdym przesłaniu przez FTP.

Najlepsze praktyki bezpieczeństwa wykraczające poza uprawnienia

Prawidłowe uprawnienia plików to tylko jedna warstwa bezpieczeństwa. Rozważ te dodatkowe środki:

  • Ogranicz dostęp do plików konfiguracyjnych: Plik app/config/parameters.php zawiera Twoje dane logowania do bazy danych. Upewnij się, że jest czytelny tylko dla użytkownika serwera WWW (uprawnienia 640), a nie dla wszystkich.
  • Wyłącz listowanie katalogów: Dodaj Options -Indexes do konfiguracji Apache lub autoindex off; do Nginx, aby uniemożliwić odwiedzającym przeglądanie zawartości katalogów.
  • Chroń pliki .htaccess: PrestaShop umieszcza pliki .htaccess w wrażliwych katalogach. Nie usuwaj ich.
  • Usuń katalog instalacyjny: Po instalacji całkowicie usuń katalog /install/. PrestaShop ostrzega o tym, ale warto to podkreślić.
  • Ustaw prawidłowy umask: Skonfiguruj serwer WWW i PHP-FPM z umaską 0022, aby nowe pliki były tworzone z uprawnieniami 644/755 domyślnie.

Rozumiejąc uprawnienia Linuxa, dopasowując je do swojego środowiska hostingowego i stosując wytyczne z tego artykułu, unikniesz najczęstszych problemów z uprawnieniami w PrestaShop, jednocześnie utrzymując bezpieczną konfigurację serwera.

Czy ta odpowiedź była pomocna?

Masz jeszcze pytania?

Can't find what you're looking for? Send us your question and we'll get back to you quickly.

Loading...
Back to top