Praca z kontami w Unixie i Linuksie wymaga precyzji, bo jedna zła sesja potrafi zmienić zwykły błąd w problem administracyjny. Polecenie su daje szybki dostęp do innego użytkownika, ale równie szybko potrafi namieszać w środowisku, jeśli nie rozumiesz, co robi z powłoką, katalogiem roboczym i zmiennymi. Poniżej rozkładam to na proste zasady: kiedy używać tego mechanizmu, jak działa krok po kroku i kiedy lepiej sięgnąć po bezpieczniejszą alternatywę.
Najważniejsze fakty o przełączaniu użytkownika
- To narzędzie uruchamia powłokę albo pojedynczą komendę z innym kontekstem użytkownika i grupy.
- Wariant z myślnikiem lub opcją login najczęściej daje najbardziej przewidywalne środowisko.
- Bez pełnego logowania łatwo odziedziczyć stary katalog roboczy, zmienne i błędny
PATH. - Do jednorazowych zadań administracyjnych często lepsze jest
sudo, bo nie otwiera pełnej sesji. - Do skryptów uruchamianych przez root sensowniejszy bywa
runuser.
Czym jest polecenie zmiany użytkownika
W praktyce chodzi o chwilową zmianę tożsamości procesu. Zamiast działać jako aktualnie zalogowane konto, uruchamiasz powłokę lub pojedyncze polecenie jako inny użytkownik, najczęściej administrator. To ważne nie tylko przy zadaniach serwisowych, ale też przy sprawdzaniu praw dostępu, odtwarzaniu problemów zgłaszanych przez konkretne konto albo pracy na kontach technicznych, które nie powinny być używane na co dzień.
Ja patrzę na ten mechanizm jak na narzędzie do zmiany kontekstu, a nie tylko do „wejścia na roota”. Ta różnica jest istotna, bo sam fakt przełączenia nie wystarcza, jeśli środowisko dalej pamięta stare ustawienia i ścieżki. Właśnie dlatego tak ważne jest, czy uruchamiasz zwykłą sesję, czy pełny login shell. Żeby zobaczyć, skąd biorą się różnice, trzeba przejść do działania krok po kroku.
Jak działa sesja po przełączeniu
Po uruchomieniu polecenia system zwykle prosi o hasło konta docelowego, a potem startuje powłokę albo przekazuje wskazaną komendę. Jeśli nie podasz nazwy użytkownika, standardowo otwierana jest sesja administratora. Jeśli podasz konto inne niż root, zachowanie zależy od uprawnień i konfiguracji systemu, ale zasada jest prosta: logujesz się do cudzej tożsamości, więc zyskujesz jej prawa, katalog domowy i konfigurację shellową.
su
su - jan
su -c 'whoami'Najbardziej przewidywalny jest tryb login, czyli wariant z myślnikiem albo odpowiednią opcją. W takim przypadku środowisko jest czyszczone i budowane od nowa: ustawiane są m.in. HOME, SHELL, USER, LOGNAME i PATH, a katalog roboczy przechodzi do katalogu domowego konta docelowego. Dokumentacja man7.org zwraca uwagę, że właśnie ten tryb ogranicza większość ubocznych efektów starych zmiennych. Ja traktuję go jako domyślny wybór, bo dzięki temu łatwiej uniknąć sytuacji, w której coś działa „tylko przez przypadek”.
Jeśli potrzebujesz tylko jednej komendy, a nie całej sesji, możesz przekazać ją przez -c. To wygodne przy prostych czynnościach administracyjnych i testach, bo nie zostawiasz otwartego konta z większymi uprawnieniami dłużej niż trzeba. Na tym tle dobrze widać, że nie wszystkie warianty są sobie równe, więc warto je uporządkować.
Najważniejsze warianty i kiedy ich używać
| Wariant | Co robi | Kiedy ma sens | Na co uważać |
|---|---|---|---|
su |
Otwiera sesję domyślnego konta administracyjnego albo wskazanego użytkownika bez pełnego resetu środowiska. | Gdy chcesz szybko wejść do innej tożsamości i wiesz, co dzieje się z otoczeniem procesu. | Łatwo odziedziczyć stary PATH, katalog roboczy i zmienne z poprzedniej sesji. |
su - |
Uruchamia pełny login shell z czystszym środowiskiem. | Gdy potrzebujesz zachowania podobnego do świeżego logowania tego użytkownika. | Zmienia katalog domowy i może inaczej ustawić dostępność poleceń. |
su nazwa_użytkownika |
Przełącza na wskazane konto, jeśli masz do tego prawo i właściwe hasło. | Przy testach uprawnień, debugowaniu konta albo pracy na koncie serwisowym. | Nie zakładaj, że zobaczysz dokładnie te same ustawienia co przy normalnym logowaniu. |
su -c 'komenda' |
Uruchamia pojedynczą komendę i kończy działanie. | Do jednorazowych czynności, gdy pełna sesja byłaby zbędna. | To nie jest wygodny zamiennik dla długich sekwencji poleceń. |
runuser -u nazwa -- komenda |
Działa podobnie, ale bez pytania o hasło, zwykle w kontekście roota. | W skryptach i zadaniach systemowych, gdzie to root kontroluje uruchomienie. | Nie myl tego z narzędziem do pracy interaktywnej dla zwykłego użytkownika. |
W praktyce najczęściej wybieram pełny login shell wtedy, gdy chcę odtworzyć rzeczywisty kontekst innego konta, a nie tylko odpalić jedną komendę. To małe rozróżnienie, ale właśnie ono decyduje o tym, czy wynik będzie wiarygodny. Z tej perspektywy naturalnie przechodzimy do porównania z narzędziami, które rozwiązują podobny problem inną drogą.
Czym różni się to od sudo i runuser
Jeśli porównujesz te narzędzia, nie patrz tylko na to, czy „da się zrobić to samo”. Liczy się model uprawnień, zakres działania i ślad audytowy. Red Hat dobrze podsumowuje tę różnicę: sudo pozwala wykonać pojedynczą czynność bez wchodzenia w pełną tożsamość innego użytkownika, a runuser jest lepszy tam, gdzie kontekst uruchamia już root. Ja zwykle zaczynam od pytania: czy naprawdę potrzebuję całej sesji, czy tylko jednego polecenia?
| Narzędzie | Wymaga hasła | Zakres | Najlepsze zastosowanie | Plus | Minus |
|---|---|---|---|---|---|
su |
Tak, zwykle hasła konta docelowego. | Pełna zmiana użytkownika i powłoki. | Praca w cudzym kontekście, testy, administracja. | Proste i szybkie. | Łatwo zostaje stare środowisko, jeśli pominiesz login shell. |
sudo |
Tak, zwykle własnego hasła użytkownika. | Pojedyncze polecenie albo ograniczony zestaw poleceń. | Codzienna administracja z kontrolą dostępu. | Lepszy audyt i mniejszy zakres uprawnień. | Wymaga dobrej konfiguracji sudoers. |
runuser |
Nie. | Zmiana użytkownika w kontekście roota. | Skrypty, zadania systemowe, automatyzacja. | Brak interaktywnego pytania o hasło. | Nie jest narzędziem dla zwykłej, ręcznej pracy użytkownika. |
Najkrócej: do jednej komendy wybieram najpierw sudo, do pełnej zmiany tożsamości dopiero potem rozważam przełączenie użytkownika. To podejście ogranicza ryzyko, a jednocześnie nie zabiera wygody tam, gdzie pełna sesja naprawdę ma sens. Gdy już wiesz, które narzędzie rozwiązuje który problem, pozostaje jeszcze kwestia błędów, które psują efekt nawet przy poprawnej składni.
Najczęstsze błędy, które psują efekt albo bezpieczeństwo
Najwięcej problemów nie wynika z samej komendy, tylko z założeń użytkownika. Oto miejsca, w których najłatwiej się potknąć:
| Objaw | Najczęstsza przyczyna | Co zrobić |
|---|---|---|
| Komendy znikają po przełączeniu | Dziedziczysz stary PATH albo konfigurację powłoki. |
Użyj trybu login i sprawdź, jakie katalogi są faktycznie dostępne. |
| Sesja zachowuje się inaczej niż oczekujesz | Stary katalog roboczy i stare zmienne środowiskowe mieszają się z nowym kontem. | Po przełączeniu zweryfikuj pwd i podstawowe zmienne powłoki. |
| Skrypt pyta o hasło | Wykorzystano narzędzie interaktywne tam, gdzie potrzebna jest automatyzacja. | W skryptach lepiej użyć narzędzia przeznaczonego do pracy nieinteraktywnej. |
| Ryzyko przypadkowego wykonania polecenia w złym terminalu | Sesja administracyjna współdzieli terminal z inną sesją. | W sytuacjach wrażliwych użyj pojedynczej komendy albo izolowanego terminala. |
| Dostęp jest przyznany zbyt szeroko | Każdy zna pełne hasło administratora albo ma nieograniczoną możliwość wejścia na konto techniczne. | Ograniczaj uprawnienia do tego, co naprawdę potrzebne, zamiast oddawać pełny dostęp. |
Jeśli miałbym wskazać jedną zasadę bezpieczeństwa, powiedziałbym tak: nie otwieraj pełnej sesji administracyjnej, jeśli nie musisz. To właśnie pełna sesja najłatwiej prowadzi do pomyłek, a na współdzielonym terminalu może też zwiększać ryzyko wstrzyknięcia znaków do aktywnej powłoki. W praktyce lepsze są krótsze, celowe sesje albo pojedyncze komendy, bo ograniczają czas ekspozycji. Po odfiltrowaniu tych błędów zostaje już prosty schemat codziennej pracy.
Najkrótsza reguła, którą warto przyjąć przy pracy z kontami
- Jeśli potrzebujesz jednej czynności, wybierz narzędzie do pojedynczej komendy zamiast pełnej sesji.
- Jeśli chcesz odtworzyć realne środowisko innego użytkownika, użyj pełnego logowania i sprawdź, czy masz właściwy
PATH. - Jeśli uruchamiasz zadanie z poziomu roota, rozważ rozwiązanie bez pytania o hasło.
- Przed zmianą czegokolwiek ważnego sprawdź
whoami,id,pwdiecho $PATH.
Największą różnicę robi nie sama komenda, lecz nawyk: przełączać się tylko wtedy, gdy naprawdę trzeba, a potem od razu wracać do zwykłego konta. To prosty odruch, który oszczędza czas, zmniejsza ryzyko błędów i pomaga zachować porządek w pracy z systemem.
