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
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:
Utiliser l’option ”
sudo -E
” – ne fonctionnait pas. Mon PATH existant était toujours réinitialisé par sudoChanger ”
Defaults env_reset
” à ”Defaults !env_reset
” dans / etc / sudoers – ne fonctionnait pas non plus (même en combinaison avec sudo -E)Ne
env_reset
commenterenv_reset
(par exemple ”#Defaults env_reset
“) dans / etc / sudoers – ne fonctionnait pas non plus.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.