uprawnienia plików

Uprawnienia plików to ustawienia praw odczytu, zapisu i wykonania plików oraz katalogów na serwerze, przypisane osobno właścicielowi, grupie i pozostałym użytkownikom. Dokumentacja WordPressa zaleca typowo 644 dla plików i 755 dla katalogów, przy czym pliki mają być zapisywalne tylko przez konto użytkownika, a czytelne dla wszystkich, w tym serwera WWW ^[2]. Zbyt szerokie prawa MITRE opisuje jako słabość CWE-732: nadanie zasobowi krytycznemu uprawnień, które pozwalają na jego odczyt lub modyfikację niezamierzonym podmiotom ^[3].

Jak działa

W systemach uniksowych każdy plik ma właściciela, grupę i trzy zestawy praw. Dokumentacja WordPressa wyjaśnia zapis liczbowy: odczyt ma wartość 4, zapis 2, wykonanie 1, a wartości sumuje się osobno dla właściciela, grupy i pozostałych ^[1]. Tryb 755 oznacza więc pełne prawa właściciela (7) oraz odczyt i wykonanie dla grupy i pozostałych (5) ^[1]. Dla katalogu „wykonanie” oznacza prawo wejścia do niego.

Uprawnienia działają razem z pytaniem, kto jest właścicielem pliku i jako kto działa proces PHP. Dokumentacja podaje, że serwer Apache często działa z konta www-data, dhapache albo nobody ^[1]. Na hostingu z suexec proces PHP działa jako właściciel plików PHP ^[1], więc tam liczy się głównie to, czy inni użytkownicy serwera mają dostęp.

Sekurak pokazuje tę samą zasadę na katalogach domowych: polecenie chmod -R 750 odcina innych użytkowników systemu od cudzego katalogu ^[5].

find /var/www/example.com -type d -exec chmod 755 {} \;
find /var/www/example.com -type f -exec chmod 644 {} \;
chmod 440 /var/www/example.com/wp-config.php

W WordPressie

Dokumentacja WordPressa opisuje schemat uprawnień wprost. Wszystkie pliki powinny należeć do konta użytkownika i być przez nie zapisywalne ^[2]. Wyjątkiem jest .htaccess, jeśli WordPress ma sam generować reguły przepisywania adresów ^[2]. Każdy plik, który WordPress musi zapisywać, powinien być zapisywalny przez serwer WWW ^[2].

Dla hostingu współdzielonego z suexec dokumentacja zaleca katalogi 755 albo 750, pliki 644 albo 640, a wp-config.php 440 albo 400, żeby inni użytkownicy serwera nie mogli go odczytać ^[1]. Ten sam limit dotyczy zwykłej konfiguracji: tylko właściciel i serwer WWW powinni móc czytać wp-config.php ^[2]. Szerzej opisuje to utwardzanie pliku wp-config.php.

Niektóre wtyczki wymagają zapisu w /wp-content/; dokumentacja radzi zaczynać od ostrożnych ustawień i zwiększać je tylko w razie potrzeby ^[1]. Katalog przesyłanych plików musi być zapisywalny, dlatego uzupełnia się go o blokadę wykonywania PHP w katalogu uploads.

Z uprawnieniami systemu plików łączy się też uprawnienie aplikacyjne. Stała DISALLOW_FILE_EDIT w wp-config.php działa jak odebranie wszystkim użytkownikom zdolności edit_themes, edit_plugins i edit_files ^[2], co wyłącza edytor plików motywów i wtyczek. Jeśli pliki PHP są zapisywalne przez proces serwera, taki edytor pozwala administratorowi, a po przejęciu konta także napastnikowi, zmieniać kod strony z panelu.

Zagrożenia i skutki

MITRE wymienia trzy grupy skutków zbyt szerokich uprawnień: odczyt danych aplikacji, na przykład poświadczeń w plikach konfiguracyjnych; zdobycie uprawnień przez podmianę plików wykonywalnych na złośliwy kod; oraz zniszczenie lub uszkodzenie danych ^[3].

Dokumentacja WordPressa ostrzega przed trybem 777, który czyni plik zapisywalnym dla wszystkich ^[1]. Najgorszy scenariusz to według niej wgranie przez napastnika złośliwego pliku albo modyfikacja istniejącego tak, by wykonywał kod ^[1]. Wtedy atakujący może przejąć kontrolę nad witryną, łącznie z danymi dostępowymi do bazy ^[1]. Przebieg pokazuje schemat poniżej.

RYS. 1Nadużycie katalogu z prawami 777

MITRE podkreśla, że szczególnie groźne są zbyt szerokie prawa do konfiguracji programu, logiki wykonania i danych wrażliwych użytkowników ^[3]. Ta sama słabość obejmuje dziś nie tylko pliki na dysku, ale też źle skonfigurowane zasoby w chmurze, dostępne dla anonimowych użytkowników ^[3]. Zalecenie konfiguracyjne MITRE jest proste: pliki konfiguracyjne i wykonywalne mają być czytelne i zapisywalne tylko dla administratorów ^[3].

Na hostingu współdzielonym zbyt szerokie prawa odczytu są groźne także bez błędu w samej stronie: inne konto na tym samym serwerze może przeczytać wp-config.php, stąd zalecenie 440 albo 400 ^[1]. Zapisywalny kod ułatwia też utrwalenie po włamaniu, na przykład pozostawienie webshella albo tylnej furtki, i sprzyja podmianie treści strony (defacement).

Dobre praktyki

• Minimalne prawa. Zgodnie z zasadą najmniejszych uprawnień pliki 644, katalogi 755, a gdzie to możliwe 640 i 750 ^{[1] [2]}.
• Nigdy 777. Dokumentacja WordPressa mówi, że żaden katalog nie powinien mieć 777 ^[1]; MITRE jako przykład błędu podaje właśnie chmod 0777 ^[3].
• Restrykcyjne ustawienia domyślne. MITRE zaleca ustawienie najbardziej restrykcyjnych praw domyślnych i maski umask przy starcie programu ^[3] oraz sprawdzanie, czy krytyczne zasoby nie mają zbyt szerokich praw ^[3].
• Właściwy właściciel. Pliki należą do konta użytkownika, nie do procesu serwera ^[2]; zmiany wgrywa się przez SFTP.
• Kontrola zmian. Uprawnienia nie zastąpią monitorowania integralności plików, które pokaże, że coś jednak zostało zmienione.

Historia i przykłady

Błędne uprawnienia zdarzają się nie tylko na serwerach WWW. CERT Polska 26 marca 2025 roku opisał podatność CVE-2025-2098 w programie Fast CAD Reader dla macOS: aplikacja była instalowana z uprawnieniami rwxrwxrwx ^[4]. Pozwalało to gościom, innym użytkownikom i aplikacjom na eskalację uprawnień przez podmianę bibliotek (Dylib Hijacking) ^[4]. Podatność dotyczyła wersji do 4.1.5, a producent przestał odpowiadać, więc według komunikatu także późniejsze wersje mogą być podatne ^[4].