Jak czytać uprawnienia plików, jakie wartości ustawić w WordPressie, czemu 777 to proszenie się o kłopoty i dlaczego winny bywa właściciel pliku, nie chmod.
Trzy cyfry - 644, 755, 600 - decydują o tym, kto może czytać, zmieniać i uruchamiać pliki Twojej strony. Źle ustawione uprawnienia dają dwa rodzaje kłopotów: zbyt luźne (osławione 777) otwierają drzwi do nadpisania plików przez złośliwy kod, zbyt ciasne kończą się białą stroną, błędami przy wgrywaniu zdjęć albo wtyczką, która „nie może zapisać ustawień". Ten poradnik tłumaczy system uprawnień od zera i podaje wartości, które po prostu działają na hostingu współdzielonym.
Każdy plik na serwerze ma trzy grupy uprawnień: dla właściciela pliku, dla grupy i dla wszystkich pozostałych. Każda grupa to suma trzech składników:
| Składnik | Wartość | Co pozwala |
|---|---|---|
| odczyt (r) | 4 | otworzyć i przeczytać zawartość |
| zapis (w) | 2 | zmienić lub usunąć |
| wykonanie (x) | 1 | uruchomić plik; dla katalogu - wejść do środka |
Stąd 644 czyta się tak: właściciel 6 (4+2 = odczyt i zapis), grupa 4 (tylko odczyt), pozostali 4 (tylko odczyt). A 755: właściciel może wszystko (4+2+1), grupa i pozostali mogą czytać i wchodzić (4+1). Jedyna nieoczywista rzecz to znaczenie „wykonania" dla katalogów - bez tego bitu nie da się wejść do katalogu, dlatego katalogi potrzebują 755 tam, gdzie plikom wystarcza 644.
Na hostingu współdzielonym z izolacją kont (tak działają nasze serwery) obowiązuje prosty standard:
| Co | Uprawnienia | Uwagi |
|---|---|---|
| wszystkie katalogi | 755 | łącznie z wp-content i uploads |
| wszystkie pliki | 644 | PHP, CSS, obrazy - bez wyjątku dla „wykonywalności": skrypty PHP nie potrzebują bitu x, uruchamia je interpreter |
| wp-config.php | 600 | zawiera hasło do bazy - nikt poza właścicielem nie ma czego w nim szukać |
| .htaccess | 644 | jak zwykły plik |
To cała tabela. Jeśli jakiś poradnik każe ustawiać inne wartości „żeby wtyczka zadziałała", problem prawie na pewno leży gdzie indziej - najczęściej w niewłaściwym właścicielu plików, o czym za chwilę.
777 oznacza: każdy proces na serwerze może ten plik nadpisać. Rada „ustaw 777, to zadziała" pochodzi z czasów serwerów, gdzie PHP działało jako inny użytkownik niż właściciel plików - luzowanie uprawnień maskowało tamten problem konfiguracji. Na współczesnym hostingu z PHP działającym na koncie użytkownika 777 niczego nie naprawia, a przy jakiejkolwiek luce w izolacji lub złośliwym kodzie na koncie robi z pliku tablicę ogłoszeń dla atakującego. W praktyce sprzątania po włamaniach pliki i katalogi 777 to pierwsze miejsca, gdzie znajdujemy obce wstawki. Jeżeli coś „działa tylko na 777" - nie luzuj uprawnień, tylko znajdź prawdziwą przyczynę.
Każdy plik ma właściciela. Na hostingu wszystkie pliki strony powinny należeć do Twojego użytkownika konta. Problemy z właścicielem powstają zwykle po:
Objawy są mylące, bo wyglądają jak problem z uprawnieniami: WordPress prosi o dane FTP przy instalacji wtyczek, nie można wgrywać mediów, aktualizacje kończą się błędem zapisu - mimo poprawnych 644/755. Samodzielnie właściciela nie zmienisz (wymaga to uprawnień administratora serwera) - w takiej sytuacji po prostu napisz do pomocy hostingu. Na naszych serwerach dodatkowo działa automat, który co kilkanaście minut prostuje właściciela i tryby plików w katalogach stron - typowe skutki nieudanych migracji naprawiają się same.
Przez klienta FTP: w FileZilli kliknij plik lub katalog prawym przyciskiem - Uprawnienia pliku. Zobaczysz wartość liczbową i możesz ją zmienić; przy katalogu jest też opcja rekursji z rozróżnieniem na pliki i katalogi. Podstawy pracy z FileZillą opisuje osobny poradnik.
Przez SSH - dwie komendy prostują całą instalację (uruchamiane w katalogu strony):
find . -type d -exec chmod 755 {} +find . -type f -exec chmod 644 {} +chmod 600 wp-config.php
Pierwsza ustawia wszystkie katalogi na 755, druga wszystkie pliki na 644, trzecia domyka konfigurację. Ta kolejność jest bezpieczna i idempotentna - można ją uruchamiać wielokrotnie. Jeżeli SSH to dla Ciebie nowość, zacznij od instrukcji połączenia w centrum pomocy.
Przez menedżer plików w DirectAdmin: zaznacz pliki i użyj opcji zmiany uprawnień - wygodne przy pojedynczych plikach, przy całej instalacji szybszy będzie wariant SSH.
| Objaw | Gdzie szukać |
|---|---|
| „Podaj dane FTP" przy instalacji wtyczki | pliki mają cudzego właściciela - zgłoś do hostingu |
| nie można wgrać zdjęcia do biblioteki | katalog wp-content/uploads: właściciel lub brak 755 na którymś poziomie |
| błąd 403 na całej stronie | katalog public_html lub index bez prawa odczytu; bywa też skutkiem reguł .htaccess |
| wtyczka „nie może zapisać ustawień" | zapis idzie do pliku w wp-content - sprawdź właściciela, nie luzuj do 777 |
| po migracji nic nie da się edytować | archiwum rozpakowane z zachowaniem obcych właścicieli |
Szerszy przegląd błędów, z którymi myli się temat uprawnień, znajdziesz w przewodniku po błędach HTTP.
Poprawne uprawnienia nie zatrzymają ataku przez dziurawą wtyczkę - kod działający na Twoim koncie ma te same prawa co Ty. Ich rola jest inna: ograniczają pole rażenia i eliminują najbardziej prymitywne wektory (zapis przez „wszystkich"), a wp-config.php na 600 chroni hasło do bazy przed odczytem w razie częściowych błędów konfiguracji. Traktuj je jako jeden z elementów układanki, obok aktualizacji, mocnych haseł i blokady wykonywania PHP w uploads - całość składamy w poradniku o hardeningu WordPressa. A jeśli podejrzewasz, że na koncie już doszło do infekcji, zacznij od instrukcji usuwania wirusa - samo prostowanie uprawnień nie usunie wgranych backdoorów.
Katalogi 755, pliki 644, wp-config.php 600 - te trzy wartości zamykają temat na zdrowym hostingu. Nigdy 777; a gdy mimo poprawnych trybów WordPress nie może zapisywać, niemal na pewno chodzi o właściciela plików, nie o uprawnienia - to naprawia hosting, nie suwak w FileZilli. Dwie komendy find z tego poradnika warto mieć w notatkach: po każdej migracji prostują instalację w kilka sekund.
Wszystkie poradniki z kategorii: WordPress