Pour lancer un shell root sur des machines sur lesquelles le compte root est désactivé, vous pouvez exécuter l’une des opérations suivantes:

• sudo -i: exécuter un shell de connexion interactif (reads /root/.bashrcet /root/.profile)
• sudo -s: exécuter un shell interactif sans connexion (reads /root/.bashrc)

Dans le monde Ubuntu, je vois très souvent sudo susuggéré comme un moyen d’obtenir un shell root. Pourquoi exécuter deux commandes distinctes quand on va faire? Autant que je sache, sudo -iest équivalent à sudo su -et sudo -sidentique à sudo su.

Les seules différences semblent être (en comparant sudo -ià gauche et sudo su -à droite):

Et en comparant sudo -s(à gauche) et sudo su(à droite):

Les principales différences (en ignorant les SUDO_foovariables et LS_COLORS) semblent être les XDG_foovariables système dans les sudo suversions.

Existe-t-il des cas où cette différence justifie l’utilisation de l’inélégant sudo su? Puis-je dire en toute sécurité aux gens (comme je le fais souvent) qu'il n'y a jamais de raison de courir sudo suou est-ce que je manque quelque chose?

Comme vous l'avez dit dans votre question, la principale différence est l'environnement.

sudo su - contre. sudo -i

En cas de sudo su -c'est un shell de connexion, donc /etc/profile, .profileet .bashrcsont exécutés et vous vous trouverez dans le répertoire de root avec l'environnement racine.

sudo -iest presque identique à sudo su -L' -ioption (connexion initiale simulée) exécute le shell spécifié par l'entrée de la base de données de mots de passe de l'utilisateur cible en tant que shell de connexion. Cela signifie que les fichiers de ressources spécifiques à la connexion, tels que .profile, .bashrcou .loginseront lus et exécutés par le shell.

sudo su contre. sudo -s

sudo suappelle sudoavec la commande su. Bash est appelé shell interactif sans connexion. Donc, bashseulement exécute .bashrc. Vous pouvez voir qu'après le passage à la racine, vous êtes toujours dans le même répertoire:

user@host:~$ sudo su
root@host:/home/user#

sudo -slit la $SHELLvariable et exécute le contenu. Si $SHELLcontient, /bin/bashil appelle sudo /bin/bash, ce qui signifie qu'il /bin/bashest lancé en tant que shell sans connexion, de sorte que tous les fichiers de points ne sont pas exécutés, mais lus bash. bashrcde l'appelant. Votre environnement reste le même. Votre maison ne sera pas la maison de root. Donc, vous êtes root, mais dans l'environnement de l'utilisateur appelant.

Conclusion

Le -idrapeau a été ajouté sudoen 2004 afin de fournir une fonction similaire à sudo su -celle sudo su -du modèle sudo -i. Je pense que ce que vous utilisez importe peu, sauf si l'environnement n'est pas important.

Une addition

Un point fondamental qui doit être mentionné ici est qu'il a sudoété conçu pour exécuter une seule commande avec des privilèges plus élevés, puis abandonner ces privilèges à ceux d'origine. Cela n'a jamais été fait pour vraiment changer d' utilisateur et laisser ouverte un shell root. Au fil du temps, sudode tels mécanismes ont été étendus, car les gens étaient agacés par la raison pour laquelle ils devaient utiliser sudodevant chaque commandement.

Donc, le sens de a sudoété abusé. sudoétait destiné à encourager l'utilisateur à minimiser l'utilisation des privilèges root.

Ce que nous avons maintenant, sudodevient de plus en plus populaire. Il est intégré dans presque toutes les distributions Linux bien connues. L'outil d'origine pour passer à un autre compte d'utilisateur est su. Pour un vétéran de la vieille école, une telle chose sudopourrait sembler inutile. Il ajoute de la complexité et se comporte plus probablement aux mécanismes connus de Microsofts os-family et va donc à l’encontre de la philosophie de la simplicité des systèmes * nix.

Je ne suis pas vraiment un ancien combattant, mais à mon avis, cela sudoa toujours été une épine dans mon côté, à partir du moment où il a été présenté et j'ai toujours travaillé sur l'utilisation de sudo, si c'était possible. Je suis très réticent à utiliser sudo. Sur tous mes systèmes, le compte root est activé. Mais les choses changent, peut-être que le moment viendra, quand susera obsolète et sudoremplace sucomplètement.

Par conséquent, je pense qu'il sera préférable d'utiliser sudoles mécanismes internes ( -s, -i) au lieu de s'appuyer sur un ancien outil tel que su.

Pour répondre directement à votre question: non, il n’ya aucune bonne raison de le faire. En outre, sudo su produit deux entrées de journal lorsqu'une suffirait.

J'ai vu beaucoup de gens faire cela, et quand je leur demande pourquoi ils ne se contentent pas de courir sudo -s, la réponse est simplement qu'ils ne connaissent pas le -sdrapeau au sudo, et en général, ils basculent après que je le signale.

Cependant, à votre liste de sudo -set sudo -i, j'aimerais ajouter une option supplémentaire sudo -sE, qui remplace en quelque sorte su -m. sudo -sEpréserve votre environnement, y compris le répertoire de base. Cela présente des risques si votre répertoire personnel n'est pas sécurisé (sur NFS). Mais dans un environnement où beaucoup de gens utilisent root, cela vous évite d'avoir à vous entendre sur le contenu du .bashrcfichier racine . Mon .bashrccontient de nombreuses spécialisations pour root. Par conséquent, je n'ai pas exactement le même environnement que root, mais au moins, je reçois exactement l'environnement souhaité.