su vs sudo -s vs sudo -i vs sudo bash

Avec su , vous devenez un autre user – root par défaut, mais potentiellement un autre user. Si vous dites su - , votre environnement est également remplacé par l'environnement de connection de cet user, de sorte que ce que vous voyez ne peut pas être distingué de la connection de cet user. Il est impossible que le système puisse dire ce que vous faites à un autre user à partir des actions de cet user lorsqu'il se connecte.

Les choses sont très différentes avec sudo :

• Les commands que vous exécutez via sudo s'exécutent en tant qu'user cible – root par défaut, mais modifiables avec -u – mais elles enregistrent les commands que vous exécutez, en les marquant avec votre nom d'user afin que le blâme puisse être atsortingbué par la suite. 🙂

• sudo est très flexible. Vous pouvez limiter les commands qu'un user ou un groupe d'users donné est autorisé à exécuter, par exemple. Avec su , c'est tout ou rien.

  Cette fonctionnalité est généralement utilisée pour définir les rôles. Par exemple, vous pouvez définir un groupe "sauvegardes" autorisé à exécuter dump et tar , dont chacun a besoin d'un access root pour sauvegarder correctement le disque système.

  Je mentionne ceci ici parce que cela signifie que vous pouvez donner des privilèges à quelqu'un sudo sans leur donner des capacités sudo bash ou sudo bash . Ils n'ont que les permissions nécessaires pour faire leur travail, alors qu'avec su ils ont exécuté tout le système. Cependant, si vous donnez à quelqu'un la possibilité de dire sudo vi , par exemple, il peut se vider de vi et avoir le même pouvoir qu'avec sudo -s .

• Parce qu'il prend le mot de passe du sudoer au lieu du mot de passe root, sudo isole l'autorisation entre plusieurs sudoers.

  Cela résout un problème administratif avec su , c'est-à-dire que lorsque le mot de passe root change, tous ceux qui doivent le savoir pour utiliser su doivent être informés. sudo permet aux passwords des sudoers de changer de façon indépendante. En fait, il est courant de verrouiller par mot de passe le count de l'user root sur un système avec sudo pour forcer toutes les tâches sysadmin à se faire via sudo . Dans une grande organisation avec de nombreux sudoeurs de confiance, cela signifie que lorsque l'un des sysadmins quitte, vous n'avez pas à changer le mot de passe root et à le dissortingbuer aux administrateurs qui restnt.

La principale différence entre sudo bash et sudo -s est que -s est plus court et vous permet de passer des commands à exécuter dans le shell par défaut de votre user de plusieurs façons:

1. Vous pouvez dire sudo -s some-command qui exécute some-command sous votre shell. C'est en gros un raccourci pour sudo $SHELL -c some-command .

2. Vous pouvez plutôt passer les commands à l'input standard du shell, comme sudo -s < my-shell-script . Vous pouvez utiliser ceci avec un heredoc pour envoyer plusieurs commands à un seul appel sudo , évitant de devoir taper sudo plusieurs resockets.

Ces deux comportements sont facultatifs. Bien plus souvent, vous donnez -s seul, donc il exécute interactivement la coquille de votre user. Dans ce mode, il diffère de sudo bash en ce qu'il peut exécuter un shell différent de bash puisqu'il apparaît d'abord dans la variable d'environnement SHELL , puis, s'il est désactivé, dans le paramètre de shell de connection de votre user, généralement dans /etc/passwd .

Le shell exécuté par sudo -s hérite de votre environnement user actuel. Si ce que vous voulez réellement est un environnement propre, comme vous obtenez juste après la connection, ce que vous voulez à la place est sudo -i , un ajout relativement récent à sudo . Grosso modo, sudo -i est à sudo -s comme su - est à su : il réinitialise toutes sauf quelques variables d'environnement keys et vous renvoie dans le directory de base de votre user. Si vous ne lui donnez pas non plus de commands pour s'exécuter sous ce shell via l'input standard ou sudo -i some-command , il exécutera ce shell en tant que shell de connection interactif pour que les scripts de démarrage du shell de l'user (par exemple .bash_profile ) .

Tout cela rend sudo -i beaucoup plus sûr que sudo -s . Pourquoi? Parce que si quelqu'un peut modifier votre environnement avant sudo -s , ils pourraient provoquer l'exécution de commands non intentionnelles. Le cas le plus évident est la modification de SHELL , mais cela peut également se produire less directement, par exemple via PAGER si vous dites man foo sous sudo -s .

Vous pourriez dire: «Si elles peuvent modifier PAGER , elles peuvent modifier PATH , et alors elles peuvent simplement replace un programme sudo maléfique», mais quelqu'un de paranoïaque peut dire /usr/bin/sudo /bin/bash pour éviter ce piège. Vous n'êtes probablement pas si paranoïaque que vous évitez également les pièges dans toutes les autres variables d'environnement sensibles. Avez-vous également pensé à vérifier EDITOR , par exemple, avant d'exécuter une command VCS ? Ainsi sudo -i .

Parce que sudo -i change également votre directory de travail dans le directory personnel de votre user, vous pouvez toujours utiliser sudo -s pour les situations où vous voulez restr dans le même directory que celui où vous étiez cd lors de l'exécution de sudo . Il est encore plus sûr de sudo -i et cd return à où vous étiez, cependant.

D'après un post ubuntuforums que j'ai fait il y a un moment:

Considérez l'expérience suivante:

 applic@ion:~% sudo su [sudo] password for applic: root@ion:/home/applic# env > /tmp/sudo_su_env root@ion:/home/applic# exit exit applic@ion:~% sudo -s applic .bashrc read... root@ion:~% env >/tmp/sudo_s 

Voici les différences que j'ai trouvées:

Avec sudo -s :

 HOME=/home/applic PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin reads $USER's ~/.bashrc 

Avec sudo su :

 HOME=/root PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games reads /etc/environment reads /root/.bashrc 

Notez la différence dans $HOME . Être root et avoir $HOME réglé sur la maison de l'user normal peut causer des problèmes. Par exemple, si vous exécutez une application graphique, l' ~/.Xauthority l'user normal peut être écrasée par root. Cela provoque les problèmes d'users normaux plus tard, par exemple ne pas être en mesure d'exécuter certaines applications charts via cron.

Résumer:

  corrupted by user's HOME=/root uses root's PATH env vars sudo -i YY[2] N sudo -s NY[2] Y sudo bash NY[2] Y sudo su YN[1] Y 

1. PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
2. PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin

La ligne du bas est sudo -i est la command appropriée à exécuter lorsque vous voulez un shell racine qui n'est pas corrompu par l'environnement de l'user.

su ( s ou ubstitute u ser) vous permet de changer d'user. su démarre une autre instance de shell avec les privilèges de l'user prévu. Par défaut, vous basculez vers l'user root , si nous voulons changer d'user spécifique, nous devons passer l'user comme suit:

 $ su bob # switches to bob (requires bob's password) 

sudo est un utilitaire de command line qui permet aux users d'exécuter des programmes avec les privilèges de security d'un autre user, par défaut superuser, c'est-à-dire root . Il utilise un file de configuration /etc/sudoers qui répertorie quels users ont des droits sur des actions spécifiques

sudo doit être lu comme / suːduː / . syntaxe sudo command ie s witch u ser et exécutez cette command.

• su est équivalent à sudo -i et simule un login dans le count root. Votre directory de travail sera /root , et il lira le .profile la racine, etc.

• sudo -s lance un shell en tant que root, mais ne change pas votre directory de travail.

• sudo bash où bash est la command à exécuter avec sudo . Cette command exécute bash tant que super user.