Cela dépend fortement de la façon dont vous appelez votre programme avec sudo ou su .
Par exemple. sur le système sur lequel je suis en ce moment :
.bashrc
COMMAND $HOME $USER Env. $PATH
1. sudo -i (root) root root [1]
2. sudo -s (USER) root USER /home/${USER}/bin:[1]
3. sudo /bin/bash (USER) root USER /home/${USER}/bin:[1]
4. sudo su (root) root USER [1]:/usr/games:/usr/local/games
5. sudo su - (root) root root [1]
Où [1]=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Env=Les variables d'environnement sont réinitialisées pour 1 et 5, extraites de $USER en 2,3,4.
Ainsi, un script ou un programme qui est lancé avec une option différente peut voir différents $PATH , $HOME , son shell peut lire différents .bashrc ,.profile et Variables d'environnement. Il lit le fichier lié au $HOME . Chaque utilisateur peut modifier son environnement de manière différente (variables, $PATH , .bashrc, .profile, .bash_profile, alias...). En particulier un utilisateur peut avoir un ordre différent des répertoires dans son $PATH et, par conséquent, un script peut exécuter une commande, par ex. en /home/$USER/bin à la place, celui du chemin attendu de la racine.
Vous pouvez exécuter le programme sous sudo -i comme vous étiez connecté en tant que root avec su - , mais vous pouvez avoir un comportement différent si vous l'exécutez avec sudo MyCommand ou avec su -c MyCommand .
De man su :
Dans la partie description :
L'environnement actuel est transmis au nouveau shell . La valeur de $PATH est réinitialisée à /bin:/usr/bin pour les utilisateurs normaux, ou/sbin:/bin:/usr/sbin:/usr/bin pour le superutilisateur
...
Dans la partie options :
- , -l, --login
Fournir un environnement similaire à ce à quoi l'utilisateur s'attendrait s'il s'était connecté directement .
De l'homme sudo
-i , --connexion
Exécutez le shell spécifié par l'entrée de 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 ou .login seront lus par le shell. Si une commande est spécifiée, elle est transmise au shell pour exécution via l'option -c du shell. Si aucune commande n'est spécifiée, un shell interactif est exécuté.sudotente de passer au répertoire personnel de cet utilisateur avant d'exécuter le shell. La commande est exécutée avec un environnement similaire à celui qu'un utilisateur recevrait lors de la connexion . La section Command Environment du manuel sudoers(5) documente la manière dont l'option -i affecte l'environnement dans lequel une commande est exécutée lorsque la stratégie sudoers est utilisée.
Si vous avez le sudo complet accès, vous pouvez devenir root en utilisant sudo su - , donc le point de sécurité est discutable.
En effet, il existe un moyen de discerner la différence entre un programme exécuté en tant que root et un programme exécuté sous sudo - en utilisant getuid contre geteuid - mais c'est une astuce artificielle. Pourquoi un système de correctifs ferait-il cela ?
Il y a quelques différences si vous obtenez un shell racine, comme l'a souligné @Hastur.
Si vous n'obtenez pas de shell racine, il y a plus de différences. Le membre du support peut avoir de l'expérience en essayant de faire des choses comme sudo patch -p0 < /root/patch.file où patch est exécuté en tant que root, mais < (tuyauterie à partir d'un fichier) ne l'est pas.