Qual è la differenza tra il login come utente e il cambio di utenti usando su through root?

Quando si dispone di un server di qualche tipo, è possibile accedervi tramite, ad esempio, ssh user1@ipe si può anche fare ssh root@ipper andare al proprio utente root con su privilegi e poi andare a su user1. Nel mio modo di pensare in entrambi i modi, mi dovrebbe condurre allo stesso ambiente utente (in questo caso, "user1"), ma nella mia esperienza reale non lo fa, perché in ssh user1@ipci sono cose installate che su user1non ci sono.

Perché?

SSH avvia una shell di accesso. su, per impostazione predefinita no.

In particolare, ciò significa che il ~/.profile(o file simile) per quell'utente non è di provenienza. Quindi le modifiche apportate ~/.profilenon avranno effetto. Potrebbe anche accadere che:

• anche se si avvia una shell di accesso, sono state apportate diverse modifiche a root ~/.profile, che potrebbero inquinare l'ambiente dell'utente.
  • /etc/profilee /etc/profile.d/*può applicare le impostazioni in modo diverso per utenti diversi (non per impostazione predefinita, tuttavia)
• potrebbero esserci impostazioni diverse per utenti diversi nella configurazione SSH.

• La configurazione di PAM è diversa. Ad esempio, /etc/pam.d/sshha:

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

  mentre /etc/pam.d/suha:

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

  Ciò significa che SSH si carica ~/.pam_environment, ma sunon lo è. Questo è grande, poiché ~/.pam_environmentè il posto indipendente dalla shell per le variabili di ambiente e viene applicato se si accede dalla GUI, dal TTY o SSH.

Per avviare una shell di accesso, eseguire uno dei seguenti:

su - <username>
sudo -iu <username>

Esempio:

# 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

Anche con SSH, se si esegue un comando invece di avviare una shell, non verrà eseguita una shell di accesso (notare l'assenza di ~/binnel test SSH, che è presente in su -e sudo -i). Per ottenere il vero risultato, eseguirò la mia shell come shell di accesso:

# 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

Questo è anche il motivo sudo sue sudo -ssono modi pessimi per ottenere una shell di root. Entrambi questi modi sono inquinati dall'ambiente.

Relazionato:

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

Nel complesso è principalmente una differenza strategica.

Se hai effettuato l'accesso come superutente, puoi modificare qualsiasi cosa in qualsiasi momento ... vale a dire - non c'è protezione contro errori catastrofici, dovresti passare temporaneamente a qualche altro utente per sicurezza.

Considerando che: se hai effettuato l'accesso con privilegi limitati, eviti il ​​rischio di errori catastrofici, perché devi intenzionalmente passare a su root per accedere temporaneamente a quel potere, ma ora hai la posizione di fallback predefinita per un utente sicuro .

La differenza è quindi davvero strategica, non tecnica.