Pourquoi sudo change-t-il le PATH?

Ceci est la variable PATH sans sudo:

$ echo 'echo $PATH' | sh /opt/local/ruby/bin:/usr/bin:/bin 

Ceci est la variable PATH avec sudo:

 $ echo 'echo $PATH' | sudo sh 

/ usr / local / sbin: / usr / local / bin: / usr / sbin: / usr / bin: / sbin: / bin: / usr / X11R6 / bin

Autant que je sache, sudo est supposé laisser PATH intact. Que se passe-t-il? Comment puis-je changer cela? (Ceci est sur Ubuntu 8.04).

UPDATE: pour autant que je puisse voir, aucun des scripts n’a démarré en tant que root pour modifier PATH.

De l’homme sudo:

Pour empêcher l’usurpation des commandes, sudo vérifie «.» Et «» (les deux indiquant le répertoire actuel) en recherchant une commande dans le PATH de l’utilisateur (si l’un ou les deux sont dans le PATH). Notez cependant que la variable d’environnement PATH n’est pas modifiée et transmise sans modification au programme exécuté par sudo.

    C’est une fonction agaçante une fonctionnalité de sudo sur de nombreuses dissortingbutions.

    Pour contourner ce “problème” sur Ubuntu, je fais ce qui suit dans mon ~ / .bashrc

     alias sudo='sudo env PATH=$PATH' 

    Notez que ce qui précède fonctionnera pour les commandes qui ne réinitialisent pas elles-mêmes le $ PATH. Cependant, `su ‘réinitialise son $ PATH, vous devez donc utiliser -p pour lui dire de ne pas le faire. C’EST À DIRE:

     sudo su -p 

    Au cas où quelqu’un d’autre courrait ceci et voulait simplement désactiver tous les changements de variables de chemin pour tous les utilisateurs.
    Accédez à votre fichier sudoers en utilisant la commande: visudo . Vous devriez voir la ligne suivante quelque part:

    Par défaut env_reset

    auquel vous devez append les éléments suivants sur la ligne suivante

    Valeurs par défaut!

    secure_path est activé par défaut. Cette option spécifie comment créer $ PATH lors de la création de sudo. Le point d’exclamation désactive la fonctionnalité.

    PATH est une variable d’environnement, et est donc réinitialisée par défaut par sudo.

    Vous avez besoin d’permissions spéciales pour pouvoir le faire.

    De l’ man sudo

            -E L'option -E (preserve environment) remplacera le env_reset
                option dans sudoers (5)).  Il n'est disponible que lorsque le match-
                La commande ing a la balise SETENV ou l'option setenv est définie dans sudo-
                ers (5).
    
            Les variables d'environnement à définir pour la commande peuvent également être transmises
            la ligne de commande sous la forme de VAR = valeur, par exemple
            LD_LIBRARY_PATH = / usr / local / pkg / lib.  Variables transmises à la commande
            ligne sont soumis aux mêmes ressortingctions que les variables d’environnement normales.
            ables avec une exception importante.  Si l'option setenv est définie dans
            sudoers, la commande à exécuter possède le jeu de balises SETENV ou la commande
            correspondant est ALL, l'utilisateur peut définir des variables qui seraient trop
            Caché.  Voir sudoers (5) pour plus d'informations.
    

    Un exemple d’utilisation:

     cat >> test.sh env | grep "MYEXAMPLE" ; ^D 
     sh test.sh MYEXAMPLE=1 sh test.sh # MYEXAMPLE=1 MYEXAMPLE=1 sudo sh test.sh MYEXAMPLE=1 sudo MYEXAMPLE=2 sh test.sh # MYEXAMPLE=2 

    mettre à jour

     homme 5 sudoers: 
    
          env_reset Si défini, sudo réinitialisera l'environnement pour ne contenir que
                            le LOGNAME, SHELL, USER, USERNAME et le SUDO_ * vari-
                            ables.  Toutes les variables dans l'environnement de l'appelant
                            correspondent aux listes env_keep et env_check sont ensuite ajoutées.
                            Le contenu par défaut de env_keep et env_check
                            les listes sont affichées lorsque sudo est exécuté par root avec le
                            Option -V.  Si sudo a été compilé avec le SECURE_PATH
                            option, sa valeur sera utilisée pour l’environnement PATH
                            variable.  Cet indicateur est activé par défaut.
    

    Donc, peut-être besoin de vérifier que cela est / n’est pas compilé dans

    C’est par défaut dans Gentoo

     # ( From the build Script ) .... ROOTPATH=$(cleanpath /bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/opt/bin${ROOTPATH:+:${ROOTPATH}}) .... econf --with-secure-path="${ROOTPATH}" 

    On dirait que ce bug existe depuis un bon bout de temps! Voici quelques références de bogues que vous pourriez trouver utiles (et qui pourraient vouloir vous abonner / voter, faire allusion, indice…):


    Bogue Debian # 85123 (“sudo: SECURE_PATH ne peut toujours pas être remplacé”) (à partir de 2001!)

    Il semble que le bogue n ° 20996 soit toujours présent dans cette version de sudo. Le changelog dit qu’il peut être remplacé à l’exécution mais je n’ai pas encore découvert comment.

    Ils mentionnent de mettre quelque chose comme ceci dans votre fichier sudoers:

     Defaults secure_path="/bin:/usr/bin:/usr/local/bin" 

    mais quand je le fais dans Ubuntu 8.10 au moins, cela me donne cette erreur:

     visudo: unknown defaults entry `secure_path' referenced near line 10 

    Bogue Ubuntu # 50797 (“sudo construit avec –with-secure-path est problématique”)

    Pire encore, pour autant que je sache, il est impossible de respecify dans le fichier sudoers. Si, par exemple, vous souhaitez offrir à vos utilisateurs un access facile à quelque chose sous / opt, vous devez recomstackr sudo.


    Oui. Il doit y avoir un moyen de remplacer cette “fonctionnalité” sans avoir à recomstackr. Rien de pire que les bigots de la sécurité qui vous disent ce qui convient le mieux à votre environnement et ne vous permettent pas de le désactiver.


    C’est vraiment ennuyant. Il peut être judicieux de conserver le comportement actuel par défaut pour des raisons de sécurité, mais il doit exister un moyen de le remplacer, à part la recompilation à partir du code source! De nombreuses personnes ont besoin de l’inheritance PATH. Je me demande pourquoi aucun responsable ne s’y penche, ce qui semble facile à trouver avec une solution acceptable.


    Je l’ai contourné comme ça:

     mv /usr/bin/sudo /usr/bin/sudo.orig 

    puis créez un fichier / usr / bin / sudo contenant les éléments suivants:

     #!/bin/bash /usr/bin/sudo.orig env PATH=$PATH "$@" 

    alors votre sudo régulier fonctionne exactement comme le sudo non sécurisé


    Bogue Ubuntu # 192651 (“le chemin sudo est toujours réinitialisé”)

    Étant donné qu’une copie de ce bogue a été déposée à l’origine en juillet 2006, je ne sais pas combien de temps un env_keep inefficace a été utilisé. Quels que soient les avantages de forcer les utilisateurs à utiliser des astuces telles que celles énumérées ci-dessus, les pages de manuel de sudo et de sudoers doivent certainement refléter le fait que les options de modification du PATH sont effectivement redondantes.

    Modifier la documentation pour refléter l’exécution réelle n’est pas déstabilisant et très utile.


    Bogue Ubuntu # 226595 (“impossible de conserver / spécifier PATH”)

    Je dois pouvoir exécuter sudo avec des dossiers binarys non std supplémentaires dans PATH. Ayant déjà ajouté mes exigences à / etc / environment, j’ai été surpris d’apprendre des erreurs sur les commandes manquantes lors de leur exécution sous sudo …..

    J’ai essayé de résoudre ce problème sans succès:

    1. Utiliser l’option ” sudo -E ” – ne fonctionnait pas. Mon PATH existant était toujours réinitialisé par sudo

    2. Changer ” Defaults env_reset ” à ” Defaults !env_reset ” dans / etc / sudoers – ne fonctionnait pas non plus (même en combinaison avec sudo -E)

    3. Ne env_reset commenter env_reset (par exemple ” #Defaults env_reset “) dans / etc / sudoers – ne fonctionnait pas non plus.

    4. Ajouter ‘ Defaults env_keep += "PATH" ‘ à / etc / sudoers – ne fonctionnait pas non plus.

    Clairement – malgré la documentation man – sudo est complètement codé en ce qui concerne PATH et ne permet aucune flexibilité concernant la conservation des utilisateurs PATH. Très ennuyeux car je ne peux pas exécuter de logiciel autre que celui par défaut sous les droits root avec sudo.

    Cela a semblé fonctionner pour moi

     sudo -i 

    qui prend le PATH non sudo

    Je pense qu’il est en effet souhaitable que sudo réinitialise le PATH: sinon un attaquant ayant compromis votre compte utilisateur pourrait placer des versions de tous types d’outils en backdoor sur le PATH de vos utilisateurs et ils seraient exécutés lors de l’utilisation de sudo.

    (bien sûr, le fait de réinitialiser sudo le PATH n’est pas une solution complète à ce type de problèmes, mais cela aide)

    C’est en effet ce qui se passe lorsque vous utilisez

     Defaults env_reset 

    dans / etc / sudoers sans utiliser exempt_group ou env_keep .

    Cela est également pratique car vous pouvez append des répertoires uniquement utiles pour root (tels que /sbin et /usr/sbin ) au chemin sudo sans les append aux chemins d’access de vos utilisateurs. Pour spécifier le chemin à utiliser par sudo:

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

    Fonctionne maintenant en utilisant sudo des repositorys karmiques. Détails de ma configuration:

     root@sphinx:~# cat /etc/sudoers | grep -v -e '^$' -e '^#' Defaults env_reset Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/grub-1.96/sbin:/opt/grub-1.96/bin" root ALL=(ALL) ALL %admin ALL=(ALL) ALL root@sphinx:~# cat /etc/apt/sources.list deb http://au.archive.ubuntu.com/ubuntu/ jaunty main ressortingcted universe deb-src http://au.archive.ubuntu.com/ubuntu/ jaunty main ressortingcted universe deb http://au.archive.ubuntu.com/ubuntu/ jaunty-updates main ressortingcted universe deb-src http://au.archive.ubuntu.com/ubuntu/ jaunty-updates main ressortingcted universe deb http://security.ubuntu.com/ubuntu jaunty-security main ressortingcted universe deb-src http://security.ubuntu.com/ubuntu jaunty-security main ressortingcted universe deb http://au.archive.ubuntu.com/ubuntu/ karmic main ressortingcted universe deb-src http://au.archive.ubuntu.com/ubuntu/ karmic main ressortingcted universe deb http://au.archive.ubuntu.com/ubuntu/ karmic-updates main ressortingcted universe deb-src http://au.archive.ubuntu.com/ubuntu/ karmic-updates main ressortingcted universe deb http://security.ubuntu.com/ubuntu karmic-security main ressortingcted universe deb-src http://security.ubuntu.com/ubuntu karmic-security main ressortingcted universe root@sphinx:~# root@sphinx:~# cat /etc/apt/preferences Package: sudo Pin: release a=karmic-security Pin-Priority: 990 Package: sudo Pin: release a=karmic-updates Pin-Priority: 960 Package: sudo Pin: release a=karmic Pin-Priority: 930 Package: * Pin: release a=jaunty-security Pin-Priority: 900 Package: * Pin: release a=jaunty-updates Pin-Priority: 700 Package: * Pin: release a=jaunty Pin-Priority: 500 Package: * Pin: release a=karmic-security Pin-Priority: 450 Package: * Pin: release a=karmic-updates Pin-Priority: 250 Package: * Pin: release a=karmic Pin-Priority: 50 root@sphinx:~# apt-cache policy sudo sudo: Installed: 1.7.0-1ubuntu2 Candidate: 1.7.0-1ubuntu2 Package pin: 1.7.0-1ubuntu2 Version table: *** 1.7.0-1ubuntu2 930 50 http://au.archive.ubuntu.com karmic/main Packages 100 /var/lib/dpkg/status 1.6.9p17-1ubuntu3 930 500 http://au.archive.ubuntu.com jaunty/main Packages root@sphinx:~# echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/opt/grub-1.96/sbin:/opt/grub-1.96/bin root@sphinx:~# exit exit abolte@sphinx:~$ echo $PATH /home/abolte/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/opt/grub-1.96/sbin:/opt/grub-1.96/bin:/opt/chromium-17593:/opt/grub-1.96/sbin:/opt/grub-1.96/bin:/opt/xpra-0.0.6/bin abolte@sphinx:~$ 

    C’est merveilleux de pouvoir enfin résoudre ce problème sans utiliser un hack.

     # cat .bash_profile | grep PATH PATH=$HOME/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin export PATH # cat /etc/sudoers | grep Defaults Defaults requiretty Defaults env_reset Defaults env_keep = "SOME_PARAM1 SOME_PARAM2 ... PATH" 

    Juste commenter “Defaults env_reset” dans / etc / sudoers

    env_keep simplement env_keep dans /etc/sudoers

    Cela ressemble à ceci:

    Defaults env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASURE MENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL L ANGUAGE LINGUAS XDG_SESSION_COOKIE"

    Ajoutez simplement PATH à la fin, donc après le changement, cela ressemblerait à ceci:

    Defaults env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASURE MENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL L ANGUAGE LINGUAS XDG_SESSION_COOKIE PATH"

    Fermez le terminal puis rouvrez-le.

    Secure_path est votre ami, mais si vous voulez vous dispenser de secure_path, faites-le

     sudo visudo
    

    Et append

     Valeurs par défaut exempt_group = your_goup
    

    Si vous souhaitez exempter un groupe d’utilisateurs, créez un groupe, ajoutez-y tous les utilisateurs et utilisez-le comme groupe exempté. Man 5 sudoers pour plus.

    la solution recommandée dans les commentaires sur la dissortingbution OpenSUSE suggère de changer:

     Defaults env_reset 

    à:

     Defaults !env_reset 

    et ensuite probablement pour commenter la ligne suivante qui n’est pas nécessaire:

     Defaults env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASURE MENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL L ANGUAGE LINGUAS XDG_SESSION_COOKIE" 

    commenter à la fois “Default env_reset” et “Default secure_path …” dans le fichier / etc / sudores fonctionne pour moi

    Vous pouvez également déplacer votre fichier dans un répertoire utilisé par sudoers:

      sudo mv $HOME/bash/script.sh /usr/sbin/ 

    Euh, ce n’est pas vraiment un test si tu n’ajoutes rien à ton chemin:

     bill @ bill-desktop: ~ $ ls -l / opt / pkg / bin
     total 12
     -rwxr-xr-x 1 racine racine 28 2009-01-22 18:58 foo
     bill @ bill-desktop: ~ $ qui foo
     / opt / pkg / bin / foo
     bill @ bill-desktop: ~ $ sudo su
     root @ bill-desktop: / home / bill # quel foo
     root @ bill-desktop: / home / bill # 
    

    Le PATH sera réinitialisé lors de l’utilisation de su ou sudo par la définition de ENV_SUPATH et ENV_PATH définie dans /etc/login.defs

    $ PATH est une variable d’environnement et cela signifie que la valeur de $ PATH peut différer pour un autre utilisateur.

    Lorsque vous vous connectez à votre système, votre paramètre de profil détermine la valeur de $ PATH .

    Regardons maintenant: –

     User | Value of $PATH -------------------------- root /var/www user1 /var/www/user1 user2 /var/www/html/private 

    Supposons que ce soient les valeurs de $ PATH pour un utilisateur différent. Maintenant, lorsque vous exécutez une commande avec sudo, cela signifie que l’ utilisateur root exécute cette commande.

    Vous pouvez confirmer en exécutant ces commandes sur le terminal: –

     user@localhost$ whoami username user@localhost$ sudo whoami root user@localhost$ 

    C’est la raison. Je pense que c’est clair pour vous.