Uprawnienia plików w Linuxie: chmod, chown i bezpieczna konfiguracja

Uprawnienia plików w Linuxie to jeden z tych tematów, które na początku wyglądają jak zestaw dziwnych literek: rwxr-x---, 755, chown. A potem okazuje się, że jedna nieprzemyślana zmiana potrafi odsłonić plik z hasłem, pozwolić obcej osobie podmienić dane aplikacji albo zwyczajnie zepsuć usługę.

W tym artykule zrobimy to praktycznie. Sprawdzimy, czym są właściciel i grupa, jak czytać prawa r, w i x, kiedy używać chmod, a kiedy chown. Zobaczysz też typowe błędy prowadzące do nadmiernego dostępu oraz prosty proces hardeningu: najpierw test, potem jedna zmiana, na końcu dokładnie ten sam test.

Ćwiczenia wykonuj wyłącznie na własnej maszynie wirtualnej, kontenerze albo innym środowisku testowym, do którego masz uprawnienia. Nie działaj „na szybko” na serwerze produkcyjnym. Przy uprawnieniach szybka komenda często daje szybki problem.

Co właściwie chronią uprawnienia plików w Linuxie?

System Linux nie patrzy tylko na to, czy plik istnieje. Sprawdza też, kim jesteś i co wolno Ci zrobić z tym plikiem lub katalogiem.

Po co? Wyobraź sobie mieszkanie z trzema poziomami dostępu. Właściciel ma swój komplet kluczy. Domownicy mają inny zestaw. Każda pozostała osoba dostaje tylko to, co świadomie jej udostępnisz. W Linuxie tymi trzema poziomami są: właściciel pliku, grupa pliku i inni użytkownicy systemu.

To jest zasada najmniejszych uprawnień. Dajesz dokładnie tyle dostępu, ile jest potrzebne do konkretnego zadania — ani trochę więcej. Konto aplikacji ma odczytać konfigurację? Daj mu odczyt. Nie musi jej edytować? Nie dawaj zapisu. Nie musi uruchamiać pliku? Nie dawaj wykonania.

Co nam to daje? Gdy jedno konto zostanie przejęte, zakres szkody jest mniejszy. Atakujący przejmie możliwości tego konta, ale nie powinien automatycznie dostać dostępu do całego systemu.

Właściciel, grupa i inni: jak czytać wynik ls -l

Zacznijmy od najważniejszego polecenia diagnostycznego. Przejdźmy do katalogu, w którym masz bezpieczny plik testowy, albo utwórzmy własny katalog roboczy w katalogu domowym.

mkdir -p ~/lab-uprawnienia
cd ~/lab-uprawnienia
touch notatka.txt
ls -l notatka.txt

mkdir -p tworzy katalog, a opcja -p nie zgłosi błędu, jeśli katalog już istnieje. touch tworzy pusty plik, gdy go jeszcze nie ma. Polecenie ls -l pokazuje szczegółowy widok pliku.

Wynik może wyglądać podobnie do tego:

-rw-r--r-- 1 twoj_uzytkownik twoja_grupa 0 Sep 21 12:00 notatka.txt

Nie przywiązuj się do konkretnej daty, nazwy użytkownika ani grupy — zależą od Twojego systemu. Skupmy się na układzie wyniku.

• Pierwszy znak - oznacza zwykły plik. Gdy zobaczysz d, patrzysz na katalog. Symbol l wskazuje dowiązanie symboliczne.
• Kolejne dziewięć znaków to prawa dostępu, podzielone na trzy grupy po trzy znaki.
• Pierwsza nazwa po liczbie linków to właściciel.
• Druga nazwa to grupa.

W przykładzie właścicielem jest twoj_uzytkownik, a grupą twoja_grupa. Właściciel i grupa nie są opisem dla człowieka. Są danymi, których Linux używa przy decyzji o dostępie.

A co, jeśli należysz jednocześnie do kilku grup? System może uwzględnić Twoje grupy dodatkowe. Sprawdzisz je prostym poleceniem:

id

Szukaj fragmentów uid=, gid= i groups=. Zobaczysz swój identyfikator użytkownika, grupę podstawową oraz grupy dodatkowe. To ważne podczas analizy: osoba nie musi być właścicielem pliku, aby dostać dostęp przez grupę.

r, w i x — co oznaczają prawa do pliku i katalogu?

Trzy podstawowe prawa to r, w i x. Oznaczają odpowiednio read, write i execute, czyli odczyt, zapis oraz wykonanie. Ale jest jeden haczyk: dla zwykłego pliku i dla katalogu ich znaczenie nie jest identyczne.

Zwykły plik

• r — odczyt: możesz przeczytać zawartość pliku.
• w — zapis: możesz zmieniać zawartość pliku.
• x — wykonanie: możesz uruchomić plik jako program lub skrypt, o ile jego zawartość i sposób uruchomienia na to pozwalają.

Przykład? Skrypt kopii zapasowej może mieć prawa rwx------. Właściciel może go czytać, zmieniać i uruchamiać. Grupa oraz inni nie dostają nic. To ma sens, jeśli skrypt zawiera dane dostępowe lub wykonuje wrażliwe zadania.

Katalog

• r — odczyt: pozwala wyświetlić nazwy elementów katalogu.
• w — zapis: pozwala tworzyć, usuwać i zmieniać nazwy elementów w katalogu, przy spełnieniu pozostałych warunków.
• x — wykonanie, czyli przejście/search: pozwala wejść do katalogu i przechodzić przez niego do znanych ścieżek.

Co to oznacza w praktyce? Katalog to nie zwykłe pudełko z plikami. Bardziej przypomina spis numerów mieszkań. Prawo r pozwala zobaczyć wpisy w spisie. Prawo x pozwala przejść do konkretnego mieszkania, gdy znasz numer. Bez x możesz zobaczyć nazwę, ale nie wejdziesz normalnie do zasobu w środku.

To częste źródło pomyłek. Ktoś daje plikowi dobre prawa, ale zostawia zbyt otwarty katalog nadrzędny. Albo odwrotnie: plik wygląda na dostępny, lecz brak prawa przejścia przez katalog blokuje dostęp.

Uprawnienia plików w Linuxie w formie tekstowej i liczbowej

Wróćmy do -rw-r--r--. Dziewięć znaków czytamy tak:

Ten sam zapis często zobaczysz jako liczbę ósemkową, na przykład 644. Po co liczby? Bo są krótsze i wygodne przy ustawianiu konkretnych praw.

• 4 oznacza odczyt, czyli r.
• 2 oznacza zapis, czyli w.
• 1 oznacza wykonanie, czyli x.

Dodajesz wartości w każdej trójce. 7 to 4+2+1, więc rwx. 6 to 4+2, czyli rw-. 5 to 4+1, czyli r-x. 0 oznacza brak praw.

Dlatego:

• 600 to rw------- — prywatny plik właściciela.
• 640 to rw-r----- — właściciel czyta i zapisuje, grupa czyta, inni nie mają dostępu.
• 644 to rw-r--r-- — typowy publicznie czytelny plik danych lub konfiguracji bez sekretów.
• 700 to rwx------ — prywatny katalog albo prywatny skrypt właściciela.
• 750 to rwxr-x--- — właściciel ma pełny dostęp, grupa może wejść i czytać, inni nie.
• 755 to rwxr-xr-x — częsty wariant dla katalogów i programów, które mają być dostępne do odczytu oraz przejścia dla innych.

Nie ucz się tych liczb jak tabliczki mnożenia bez kontekstu. Najpierw odpowiedz sobie: kto ma wykonać jaką czynność? Dopiero potem zapisz właściwy tryb.

chmod: zmieniaj prawa precyzyjnie, nie na ślepo

chmod zmienia prawa dostępu. Możesz podać tryb liczbowy albo symboliczny. Zacznijmy od podejścia symbolicznego, bo dobrze pokazuje intencję.

Załóżmy, że masz plik z hasłem do laboratoryjnej bazy danych. Właściciel ma go czytać i zmieniać. Nikt inny nie powinien go nawet odczytać. Najpierw sprawdźmy stan.

cd ~/lab-uprawnienia
echo 'haslo-tylko-do-labu' > sekret.env
ls -l sekret.env

Jeśli wynik pokaże prawa podobne do -rw-r--r--, grupa i inni mogą odczytać plik. To nadmiarowy dostęp. No dobra, zróbmy jedną zmianę.

chmod go-rwx sekret.env
ls -l sekret.env

g oznacza grupę, o — innych użytkowników, a -rwx odbiera im wszystkie trzy podstawowe prawa. Drugi ls -l to nasz test po zmianie.

Szukaj wyniku podobnego do -rw-------. Właściciel nadal ma odczyt i zapis, ale grupa oraz inni nie mają żadnych praw. To właśnie porównanie efektu: przed zmianą plik był potencjalnie czytelny dla większej liczby kont; po zmianie jest dostępny wyłącznie dla właściciela.

Ten sam rezultat ustawisz liczbowo:

chmod 600 sekret.env
ls -l sekret.env

600 oznacza: właściciel rw-, grupa ---, inni ---. Tryb liczbowy ustawia komplet praw dla wszystkich trzech klas naraz. To wygodne, ale wymaga pewności, co wpisujesz.

A kiedy forma symboliczna jest lepsza? Gdy nie chcesz przypadkiem skasować praw, które już są poprawne. Przykład: chcesz tylko dodać wykonanie właścicielowi skryptu.

chmod u+x backup.sh
ls -l backup.sh

u to właściciel, + dodaje prawo, a x oznacza wykonanie. Pozostałe prawa zostają bez zmian. Co nam to daje? Mniejszą szansę, że jednym poleceniem niechcący otworzysz dostęp grupie albo innym użytkownikom.

chown: zmiana właściciela i grupy

chmod odpowiada na pytanie: „Co wolno robić?”. chown odpowiada na inne: „Kto jest właścicielem i do jakiej grupy należy plik?”.

Przykład z życia: aplikacja działa na koncie technicznym www-data albo innym dedykowanym użytkowniku usługi. Plik należy do Twojego konta administracyjnego, ale proces aplikacji potrzebuje go odczytać. Masz wtedy kilka możliwości. Często rozsądniej jest przypisać właściwą grupę i nadać grupie minimalne uprawnienie niż otwierać plik dla wszystkich.

Ogólna składnia wygląda tak:

sudo chown nowy_wlasciciel:nowa_grupa plik

Dwukropek rozdziela właściciela i grupę. Gdy wpiszesz tylko nazwę właściciela, grupa nie zostanie zmieniona. Do zmiany właściciela na inne konto zwykle potrzebujesz uprawnień administracyjnych, dlatego często pojawia się sudo.

Nie uruchamiaj tej komendy z przykładowymi nazwami na ślepo. Najpierw sprawdź faktyczne konta i grupy na swojej maszynie. Możesz użyć:

id
getent group

id pokazuje informacje o bieżącym użytkowniku. getent group wyświetla grupy znane systemowi, więc wynik może być długi. Szukaj wyłącznie grupy, której faktycznie potrzebuje usługa lub zespół.

Załóżmy laboratoryjnie, że utworzyłeś grupę projekt, a plik ma być współdzielony tylko z jej członkami. Ustawienie mogłoby wyglądać tak:

sudo chown:projekt raport.txt
chmod 640 raport.txt
ls -l raport.txt

Pierwsza komenda zmienia samą grupę pliku na projekt. Zapis z samym :projekt zostawia obecnego właściciela bez zmian. Druga komenda ustawia rw-r-----: właściciel może czytać i pisać, grupa tylko czytać, inni nie mają dostępu.

Po teście szukaj nazwy projekt w kolumnie grupy oraz praw podobnych do -rw-r-----. To bezpieczniejszy wzorzec niż 644, gdy raport nie jest przeznaczony dla wszystkich kont na serwerze.

Najczęstsze błędy: gdzie pojawia się nadmierny dostęp?

1. chmod 777 jako uniwersalny „naprawiacz”

chmod 777 katalog daje pełne prawa właścicielowi, grupie i innym użytkownikom: rwxrwxrwx. Czy można tego użyć? Tak, ale wyłącznie świadomie w swoim odizolowanym środowisku testowym, gdy chcesz szybko sprawdzić hipotezę o blokadzie uprawnień. Nigdy nie traktuj tego jako ustawienia produkcyjnego.

Problem: aplikacja nie może zapisać pliku. Zły odruch: dać 777. Lepszy proces: sprawdzić właściciela, grupę, prawa katalogu i konto, na którym działa proces. Potem zmienić tylko potrzebny element.

Przykład bezpieczniejszego kierunku: jeśli aplikacja należy do określonej grupy, ustaw właściwą grupę przez chown:grupa i nadaj grupie zapis tylko tam, gdzie naprawdę musi tworzyć pliki. Na przykład katalog roboczy może potrzebować 770, ale katalog z kodem aplikacji często nie powinien być zapisywalny przez wszystkich.

2. Światowy odczyt plików z sekretami

Pliki .env, klucze prywatne, tokeny API, kopie baz danych i konfiguracje z hasłami nie powinny być czytelne dla „innych”. Jeśli widzisz dla takiego pliku końcówkę r-- albo rw- w trzeciej trójce, zatrzymaj się i sprawdź, czy to zamierzone.

Testujesz przez ls -l. Poprawiasz na przykład przez chmod 600 nazwa_pliku. Testujesz ponownie przez ls -l. Proste, powtarzalne i bez zgadywania.

3. Rekurencja bez sprawdzenia drzewa katalogów

Opcja -R w chmod lub chown działa rekurencyjnie, czyli schodzi po katalogu i jego zawartości. To bywa użyteczne, ale może być niebezpieczne. Pliki i katalogi zwykle potrzebują innych praw. Nadanie x wszystkim plikom albo odebranie go wszystkim katalogom potrafi złamać działanie aplikacji.

I teraz uwaga: rekurencyjna praca z dowiązaniami symbolicznymi wymaga szczególnej ostrożności. Nie kopiuj komend z opcjami rekurencyjnymi bez zrozumienia, co wskazują dowiązania i jaki katalog naprawdę obejmujesz.

Zamiast zaczynać od zmiany, najpierw obejrzyj strukturę:

find ~/lab-uprawnienia -maxdepth 2 -ls

find wyszukuje elementy, -maxdepth 2 ogranicza zejście do dwóch poziomów, a -ls pokazuje szczegóły. Wynik może być długi, ale dzięki niemu widzisz, czy pod wskazaną ścieżką nie leży coś, czego nie planowałeś zmieniać.

4. Zapominanie o katalogu nadrzędnym

Masz poprawne prawa pliku, a mimo to usługa dostaje „Permission denied”. Co wtedy? Sprawdź każdy katalog na ścieżce. Jeśli proces nie ma prawa x do katalogu nadrzędnego, może nie dotrzeć do pliku. Zacznij od prostego porównania:

ls -ld ~/lab-uprawnienia
ls -l ~/lab-uprawnienia/sekret.env

Pierwsza komenda dotyczy katalogu, druga pliku. Szukaj różnicy między tym, co zakładasz, a tym, co rzeczywiście widzisz.

Praktyczny hardening: zabezpiecz katalog z raportami

Zróbmy pełne ćwiczenie. Założenie jest proste: w katalogu raportów właściciel ma pełny dostęp, grupa ma móc wejść i czytać raporty, a pozostali użytkownicy nie powinni mieć żadnego dostępu.

Problem: katalog i plik mogą być zbyt szeroko dostępne. Test: sprawdzamy stan. Jedna zmiana: ustawiamy prawa osobno dla katalogu i pliku. Test ponownie: porównujemy wynik.

cd ~/lab-uprawnienia
mkdir -p raporty
echo 'raport testowy' > raporty/wynik.txt
ls -ld raporty
ls -l raporty/wynik.txt

Jeżeli zobaczysz dla katalogu coś podobnego do drwxr-xr-x i dla pliku -rw-r--r--, inni użytkownicy mogą odpowiednio przejść do katalogu i odczytać raport. W laboratorium to nie zawsze jest błąd, ale w naszym scenariuszu nie jest to potrzebne.

Teraz zmiana. Dla katalogu potrzebujemy 750, bo grupa ma wejść do środka. Dla zwykłego raportu wystarczy 640, bo grupa ma go odczytać, a nie wykonywać.

chmod 750 raporty
chmod 640 raporty/wynik.txt
ls -ld raporty
ls -l raporty/wynik.txt

Po zmianie oczekuj praw podobnych do drwxr-x--- dla katalogu i -rw-r----- dla pliku. Co to oznacza?

• Właściciel może pracować bez ograniczeń.
• Grupa może wejść do katalogu i odczytać raport.
• Inni użytkownicy nie mogą wejść do katalogu ani odczytać raportu.

No i pięknie — nie nadaliśmy wszystkim pełnego dostępu. Dopasowaliśmy dostęp do faktycznej potrzeby.

Jeżeli raport ma być prywatny nawet dla grupy, zmień prawa pliku na 600, a katalogu na 700. Jeśli zaś grupa ma również tworzyć i zmieniać raporty, możesz rozważyć prawa grupowego zapisu, ale tylko po sprawdzeniu, kto realnie należy do tej grupy.

Krótka lista kontrolna przed użyciem chmod i chown

1. Sprawdź zasób: użyj ls -l dla pliku i ls -ld dla katalogu.
2. Ustal konto procesu: pytaj, który użytkownik lub która grupa naprawdę korzysta z pliku.
3. Ustal minimalny zakres: odczyt, zapis czy wykonanie? Dla właściciela, grupy czy innych?
4. Zmieniaj małymi krokami: najpierw jeden plik albo jeden katalog w laboratorium.
5. Testuj po zmianie: uruchom ponownie ten sam ls i zweryfikuj działanie usługi w kontrolowanym środowisku.
6. Unikaj automatyzmu: 777 i -R nie są rozwiązaniem problemu, dopóki nie rozumiesz przyczyny.

Warto też pamiętać, że klasyczne prawa właściciel–grupa–inni to fundament, ale nie jedyny mechanizm dostępu w Linuxie. W bardziej rozbudowanych środowiskach mogą działać dodatkowe ACL-e, polityki bezpieczeństwa lub ograniczenia narzucone przez usługę. Jeśli proste prawa wyglądają dobrze, a dostęp nadal nie działa, nie zakładaj od razu, że system „wariuje”. Sprawdź warstwy po kolei.

FAQ: chmod, chown i prawa dostępu

Co dalej: od prostych praw do realnego Linux Hardeningu

Jeśli rozumiesz właściciela, grupę i rwx, przestajesz traktować komunikat „Permission denied” jak przypadkowy błąd. Umiesz zadać właściwe pytania: kto uruchamia proces, do jakiej należy grupy, jaki dostęp jest konieczny i czy katalog nadrzędny nie blokuje przejścia.

To jest bardzo dobry fundament pod dalszą naukę Kali Linux, administracji i testów bezpieczeństwa wykonywanych legalnie w laboratorium. Jeżeli chcesz przejść od podstaw systemu i sieci do narzędzi pentesterskich, analizy podatności oraz Linux Hardeningu, zobacz Security Starter – Kali Linux Części 1–4. To jedna ścieżka z czterema kursami w pakiecie — sensowna opcja, gdy zamiast składać wiedzę z przypadkowych materiałów chcesz ćwiczyć od fundamentów aż po zabezpieczanie systemów.

Na teraz zapamiętaj jedną rzecz: nie ustawiaj praw według gotowego numerka z internetu. Najpierw ustal, kto czego potrzebuje. Potem daj minimum. I zawsze sprawdź efekt.