Pourquoi les variables PATH sont-elles différentes lors de l'exécution avec sudo et su?

Sur ma machine virtuelle Fedora, lors de l'exécution avec mon compte d'utilisateur, j'ai /usr/local/binsur mon chemin:

[justin@justin-fedora12 ~]$ env | grep PATH
 PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/justin/bin

Et de même lors de l'exécution su:

[justin@justin-fedora12 ~]$ su -
Password: 
[root@justin-fedora12 justin]# env | grep PATH
PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/justin/bin

Cependant, lors de l'exécution via sudo, ce répertoire n'est pas dans le chemin:

[root@justin-fedora12 justin]# exit
[justin@justin-fedora12 ~]$ sudo bash
[root@justin-fedora12 ~]# env | grep PATH
PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/sbin:/bin:/usr/sbin:/usr/bin

Pourquoi le chemin serait-il différent lors de l'exécution via sudo?

Regarde /etc/sudoers. Le fichier par défaut dans Fedora (ainsi que dans RHEL et Ubuntu et similaire) comprend cette ligne:

Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin

Ce qui garantit la propreté de votre chemin lorsque vous exécutez des fichiers binaires sous sudo. Cela aide à se protéger contre certaines des préoccupations mentionnées dans cette question . C'est également pratique si vous n'en avez pas /sbinet /usr/sbinsur votre propre chemin.

La commande su -exécutera le chemin le profil de l' utilisateur root et de prendre sur l'environnement de l'utilisateur , y compris etc. sudone le fait pas.

Si vous voulez vous sudocomporter comme su -alors utilisez l'option sudo -i [commandqui exécutera le profil de l'utilisateur

Si vous souhaitez su -vous comporter comme sudoceci, n'utilisez pas le trait d'union - utilisez simplementsu [command]

Vous pouvez vérifier pourquoi (c'est différent) en exécutant sudo sudo -V.

Par exemple sous Linux, lancez:

$ sudo sudo -V | grep PATH
Value to override user's $PATH with: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

^{Remarque: sous Mac OS / BSD, il suffit d' exécuter: sudo sudo -V.}

La liste ci-dessus est restreinte en raison du plug-in de politique de sécurité par défaut dans certaines distributions Linux.

Ceci est expliqué plus en détail dans man sudoers:

Si l' secure_pathoption est définie, sa valeur sera utilisée pour la PATHvariable d'environnement.

secure_path- Chemin utilisé pour chaque commande exécutée à partir de sudo. Si vous ne faites pas confiance aux personnes qui exécutent sudo pour avoir une PATHvariable d’environnement saine , vous pouvez l’utiliser.

Une autre utilisation est si vous souhaitez que le “chemin racine” soit séparé du “chemin utilisateur”. Les utilisateurs du groupe spécifié par l' exempt_groupoption ne sont pas affectés par secure_path. Cette option n'est pas définie par défaut.

Si c'est le cas, vous pouvez modifier cela en exécutant sudo visudoet en modifiant le fichier de configuration et en modifiant votre secure_path(ajout d'un chemin supplémentaire séparé par :) ou en ajoutant votre utilisateur dans exempt_group(afin que vous ne soyez pas affecté par les secure_pathoptions).

Ou afin de passer PATHtemporaire de l'utilisateur , vous pouvez exécuter:

sudo env PATH="$PATH" my_command

et vous pouvez vérifier cela en:

sudo env PATH="$PATH" env | grep ^PATH

Voir aussi: Comment faire sudoconserver $PATH?

Une autre raison pour laquelle l’environnement pourrait être différent sudo, c’est parce que l’ env_resetoption pourrait être activée dans votre sudoersfichier. Cela provoque l'exécution de commandes avec un nouvel environnement minimal.

Vous pouvez donc utiliser l' env_keepoption (non recommandée pour des raisons de sécurité ) pour préserver les variables d'environnement de votre utilisateur:

Defaults        env_reset
Defaults        env_keep += "PATH PYTHONPATH"

Dans la plupart des linux, vous installez des programmes via la gestion des paquets et vous obtenez des mises à jour de manière régulière. Si vous installez quelque chose qui contourne la gestion des paquets, il sera installé dans / usr / local / bin (par exemple, ou ... / sbin, ou / opt) et ne recevra pas de mises à jour régulières.

Je suppose donc que les programmes ne sont pas considérés comme sécurisés et ne sont pas intégrés par défaut à PATH.

Je viens d’essayer cela moi-même et je n’ai pas vu le comportement que vous observiez - mon chemin est resté le même, alors peut-être que votre configuration sudo est différente. Si vous vérifiez, man sudoersvous verrez qu'il existe une option appelée secure_pathréinitialisation PATH- il semble que cette option a peut-être été activée.

Parce que lorsque vous utilisez sudo bash, bashne pas agir comme un shell de connexion. Réessayez avec sudo bash -let vous devriez voir le même résultat que su -.

Si cela est exact, alors la différence PATHréside dans les fichiers de configuration: /etc/profile, ~/.bash_profile, ~/.bash_login, ~/.profilesont exécutés (dans cet ordre) pour un shell de connexion, tout ~/.bashrcest exécuté pour un shell interactif sans connexion.

Vieille question, je sais, mais je suis tombé ici tout à l’heure parce que j’enquêtais sur ce problème précis.

Pour une raison quelconque /usr/local/binétait seulement dans le PATH en devenant root via sudo su -. Lors de l'utilisation, sudo -iil n'était pas là. Bien sûr, je sais maintenant que je peux l'ajouter à / etc / sudoers, mais cela n'explique toujours pas pourquoi il est déjà là après su -. D'où vient cette partie de PATH?

Après beaucoup de recherches et de recherches, j'ai trouvé la réponse:

Le chemin par défaut contenant '/ usr / local / bin' est en réalité codé en dur en su (1).

Donc, aucune configuration pam, profil, bashrc ou quoi que ce soit n'était responsable de l'ajout sélectif de cet élément. Il était toujours déjà là quand sua repris. Et comme sudon’invoque pas sudu tout mais utilise sa propre configuration, il lui manquait aprèssudo -i

J'ai trouvé que cela était vrai sur RHEL6 et RHEL7. Je n'ai vérifié aucune autre version ou distribution.