Jaka jest różnica między logowaniem jako użytkownik a zmianą użytkowników korzystających z su przez root?

Kiedy masz jakiś serwer, możesz uzyskać do niego dostęp, np. ssh user1@ipI możesz także ssh root@ipprzejść do użytkownika root z uprawnieniami su, a następnie przejść do su user1. W moim przekonaniu oba te sposoby powinny doprowadzić mnie do tego samego środowiska użytkownika (w tym przypadku „użytkownika 1”), ale z mojego rzeczywistego doświadczenia tak nie jest, ponieważ ssh user1@ipsą zainstalowane rzeczy, których su user1nie ma.

Dlaczego?

SSH uruchamia powłokę logowania. su, domyślnie nie.

W szczególności oznacza to, że ~/.profile(lub podobny plik) dla tego użytkownika nie jest pozyskiwany. Wprowadzone zmiany ~/.profilenie będą obowiązywać. Może się również zdarzyć, że:

• nawet jeśli uruchomisz powłokę logowania, w katalogu root wprowadzono różne zmiany ~/.profile, które mogą zanieczyścić środowisko użytkownika.
  • /etc/profilei /etc/profile.d/*może stosować ustawienia inaczej dla różnych użytkowników (jednak nie domyślnie)
• w konfiguracji SSH mogą obowiązywać różne ustawienia dla różnych użytkowników.

• Konfiguracja PAM jest inna. Na przykład /etc/pam.d/sshma:

  session    required     pam_env.so user_readenv=1 envfile=/etc/default/locale
  

  mając na uwadze, /etc/pam.d/suże:

  session       required   pam_env.so readenv=1 envfile=/etc/default/locale
  

  Oznacza to, że SSH ładuje się ~/.pam_environment, ale sunie. To jest duże, ponieważ ~/.pam_environmentjest niezależnym od powłoki miejscem dla zmiennych środowiskowych i jest stosowane, jeśli logujesz się z GUI, TTY lub SSH.

Aby uruchomić powłokę logowania, uruchom jedną z:

su - <username>
sudo -iu <username>

Przykład:

# su muru -c 'sh -c "echo $HOME $PATH"'
/home/muru /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
# su - muru -c 'sh -c "echo $HOME $PATH"'
/home/muru /home/muru/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
# sudo -iu muru sh -c 'echo $HOME $PATH'
/home/muru /home/muru/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# sudo -u muru sh -c 'echo $HOME $PATH'
/root /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# ssh muru@localhost 'echo $HOME $PATH'
/home/muru /home/muru/devel/go/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

Nawet w przypadku SSH, jeśli uruchomisz polecenie zamiast uruchamiania powłoki, powłoka logowania nie zostanie uruchomiona (zwróć uwagę na brak ~/bintestu SSH, który jest obecny w su -i sudo -i). Aby uzyskać prawdziwy wynik, uruchomię moją powłokę jako powłokę logowania:

# ssh muru@localhost '$SHELL -ilc "echo \$HOME \$PATH"'
/home/muru /home/muru/bin:/home/muru/devel/go/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

Jest to również powód sudo sui sudo -ssą kiepskimi sposobami na uzyskanie powłoki roota. Oba te sposoby są zanieczyszczone przez środowisko.

Związane z:

• Unix i Linux: su vs sudo -s vs sudo -i vs sudo bash

Zasadniczo jest to głównie różnica strategiczna.

Jeśli jesteś zalogowany jako superużytkownik, możesz cały czas zmieniać wszystko ... tzn. - nie ma ochrony przed katastrofalnymi błędami, dla bezpieczeństwa musisz tymczasowo zmienić się na innego użytkownika.

Podczas gdy: jeśli jesteś zalogowany z ograniczonymi uprawnieniami, unikasz pewnego ryzyka katastrofalnych błędów, ponieważ musisz celowo przejść do rootowania, aby uzyskać tymczasowy dostęp do tej mocy, ale teraz masz domyślną pozycję awaryjną dla bezpiecznego użytkownika .

Różnica jest więc naprawdę strategiczna, a nie techniczna.