Je me demandais quelle est la différence entre Sudo -i
et Sudo su
?
Basé sur les descriptions des pages de l'homme pour su
et Sudo
je suppose que les choses suivantes.
Sudo -iu <user>
désigne une coquille de connexion cela serait équivalente à un su - <user>
ou su -l <user>
.su
sans argument change votre identifiant utilisateur efficace, mais vous utilisez toujours votre original <user>
Environnement et un who am i
va signaler que vous êtes toujours <user>
.EXCERT SUDO Man
-i [command]
The -i (simulate initial login) option runs the Shell specified in
the passwd(5) entry of the target user as a login Shell. This means
that login-specific resource files such as .profile or .login will
be read by the Shell. If a command is specified, it is passed to
the Shell for execution. Otherwise, an interactive Shell is
executed. Sudo attempts to change to that user's home directory
before running the Shell. It also initializes the environment,
leaving DISPLAY and TERM unchanged, setting HOME, MAIL, Shell,
USER, LOGNAME, and PATH, as well as the contents of
/etc/environment on Linux and AIX systems. All other environment
variables are removed.
J'ai un compte d'utilisateur, saml
avec un UID de 500.
$ egrep "Uid|Gid" /proc/$$/task/$$/status
Uid: 500 500 500 500
Gid: 501 501 501 501
Dans la sortie ci-dessus, la 1ère colonne est mon UID réel (UID) et le 2e est mon UID efficace (euid).
$ su
Maintenant, je suis root, mais je maintiens toujours mon environnement et mon vrai UID est toujours 500
. Notez que mon EUID est maintenant 0 (racine).
$ egrep "Uid|Gid" /proc/$(pgrep su -n)/task/$(pgrep su -n)/status
Uid: 500 0 0 0
Gid: 501 501 501 501
Cependant, mon environnement est toujours saml
's. Voici l'une des variables d'environnement, $LOGNAME
.
$ env | grep LOGNAME
LOGNAME=saml
$ su -
Avec un su -
ou Sudo -i
Non seulement je modifie mon UID effectif à un nouvel utilisateur, mais je suis également source de leurs fichiers comme s'il s'agissait d'une connexion et que mon environnement devient désormais identique comme si j'étais leur connexion directe.
$ egrep "Uid|Gid" /proc/$(pgrep su -n)/task/$(pgrep su -n)/status
Uid: 500 0 0 0
Gid: 501 501 501 501
Cependant, mon environnement est maintenant root
's. Même variable, $LOGNAME
, maintenant, il est défini avec root
.
$ env | grep LOGNAME
LOGNAME=root
Essayons ce qui précède avec Sudo -i
et découvrir.
$ Sudo -i
Regardons maintenant les mêmes informations:
$ egrep "Uid|Gid" /proc/$(pgrep su -n)/task/$(pgrep su -n)/status
Uid: 0 0 0 0
Gid: 501 501 501 501
Bien une chose majeure est mon identifiant effectif et mon identifiant réel 0 (root
) avec cette approche. La variable d'environnement $LOGNAME
est comme si nous nous sommes connectés comme root
.
$ env | grep LOGNAME
LOGNAME=root
Si nous comptons le nombre de lignes en disant les 3 méthodes, il y a peut-être certaines informations supplémentaires.
$ env > /tmp/<method used to become root>
Nous sommes partis avec ces 3 fichiers:
Nous pouvons déjà voir que quelque chose se passe avec juste une plaine su
. L'env. est sur 2 fois la taille des autres.
Nombre de lignes dans chaque:
$ wc -l su*
28 sudash_root.txt
32 Sudo_root.txt
92 su_root.txt
Il n'y a vraiment pas besoin de regarder plus loin à la su_root.txt
déposer. Ce fichier contient une grande partie de l'environnement de l'utilisateur qui a exécuté la commande su
. Alors regardons les 2 autres fichiers.
Ils sont pratiquement identiques, sauf pour quelques variables cosmétiques, telles que $LANG
être légèrement différent. Le pistolet fumant dans la liste est le $PATH
.
sudo
PATH=/usr/lib64/ccache:/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/brlcad/bin:/root/bin
su -
PATH=/usr/lib64/qt-3.3/bin:/usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/brlcad/bin:/root/bin
Comme tu peux le voir Sudo -i
nous donne une certaine protection supplémentaire en éliminant des chemins suspects, mais il garde aussi notre $DISPLAY
et $TERM
Intact au cas où nous affichions une interface graphique à un emplacement différent.
Sudo -i
fait des avantages par rapport aux autres, car vous utilisez votre propre mot de passe pour le faire, protégeant le mot de passe de la racine de la nécessité de vous donner.root
, vs mysterieusement quelqu'un de devenir root
via su
ou su -
.Sudo -i
vous donne une meilleure expérience utilisateur sur l'une des su
'S parce qu'il protège votre $DISPLAY
et $TERM
.Sudo -i
Fournit une certaine protection au système lorsque l'utilisateur deviendra root
, en limitant l'environnement qu'ils sont donnés.Sudo su
, tu n'as même pas discuté?J'avais intentionnellement évité de l'apporter à la discussion même si l'OP a posé une question à ce sujet parce que cela ne ferait que confonduire la question, imo. Quand vous courez Sudo su
La commande Sudo
masque les effets du su
et tant de l'environnement que vous obtiendriez d'un su
est perdu. Sudo fait son travail et fournit un environnement limité et protégé, que ce soit Sudo su
ou Sudo -i
.
Voici le résultat de la Sudo su
Environnement étant largué:
ls -l /tmp/sudosu_root.txt
-rw-r--r-- 1 root root 1933 Nov 2 14:48 /tmp/sudosu_root.txt
Et le nombre de lignes:
$ wc -l /tmp/sudosu_root.txt
31 /tmp/sudosu_root.txt
Ce sont les seules variables qui diffèrent entre un Sudo su -
et un Sudo -i
:
$ sdiff /tmp/sudosu_root.txt /tmp/Sudo_root.txt | grep ' |'
USERNAME=saml | USERNAME=root
PATH=/usr/lib64/ccache:/sbin:/bin:/usr/sbin:/usr/bin:/usr/brl | PATH=/usr/lib64/ccache:/usr/local/sbin:/sbin:/bin:/usr/sbin:/
MAIL=/var/spool/mail/saml | MAIL=/var/spool/mail/root
PWD=/home/saml/tst | PWD=/root
Sudo_COMMAND=/bin/su | Sudo_COMMAND=/bin/bash
XAUTHORITY=/root/.xauthYFtlL3 | XAUTHORITY=/var/run/gdm/auth-for-saml-iZePuv/datab
Donc, comme vous pouvez le voir, il n'y a vraiment pas une grande partie de la différence entre eux. Légèrement différent $PATH
, les $Sudo_COMMAND
, et le $MAIL
et $USERNAME
sont les seules différences.
Je pense que @SLM a mal interprété la question, donc fournir une autre réponse.
Il a été frappé sur le point principal, d'une coque de connexion et de l'autre non.
[.____] lors de la course Sudo -i
La coquille deviendra une coquille de connexion, et il va donc lire des choses comme ~/.profile
Où comme une coque non-connexion ne fera que lire ~/.bashrc
.
Quand enchaînant Sudo
avec su
(comme dans Sudo su
), ni le Sudo
_ ni le su
invoquent une coque de connexion. L'équivalent à Sudo -i
Lorsque vous utilisez su
serait plutôt Sudo su -l
.
Je considère personnellement Sudo su
Pour être dans le sens des exemples "Utilisation inutile des chats". Vous pouvez obtenir le même comportement avec Sudo -s
.
Il y a essentiellement 5 manières courantes d'invoquer une coquille racine via sudo
Sudo su
HOME
à /root
Sudo -i
HOME
à /root
Sudo su -l
HOME
à /root
Lorsque vous invoquez une coquille, cela équivaut à Sudo -i
Sudo -s
HOME
à /root
Lorsque vous invoquez une coquille, cela équivaut à Sudo su
Sudo -Es
HOME
seul$PATH
et $LD_LIBRARY_PATH
IIRC)Notez que ces règles ne s'appliquent que lorsque vous les utilisez pour obtenir une coquille. Il y a une différence entre Sudo -s somecommand
et Sudo su -c somecommand
.
Le second conserve le répertoire actuel (PWD) mais la première commande goutte à l'utilisateur au répertoire de base de la racine.