这是PATH
没有sudo 的变量:
$ echo 'echo $PATH' | sh /opt/local/ruby/bin:/usr/bin:/bin
这是PATH
sudo 的变量:
$ echo 'echo $PATH' | sudo sh /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
据我所知,sudo
应该PATH
保持不变.这是怎么回事?我该如何改变?(这是在Ubuntu 8.04上).
更新:据我所知,没有任何脚本PATH
以任何方式作为root更改.
来自man sudo
:
为了防止命令欺骗,当在用户的PATH中搜索命令时(如果一个或两个都在PATH中),sudo会检查``.''和``''(都表示当前目录).但请注意,实际的PATH环境变量未被修改,并且不会更改地传递给sudo执行的程序.
pixelbeat.. 236
这是 一个烦人的功能 sudo在许多发行版上的一个特性.
要在ubuntu上解决这个"问题",我在〜/ .bashrc中执行以下操作
alias sudo='sudo env PATH=$PATH'
请注意,上述内容适用于不重置$ PATH的命令.但是`su'重置它的$ PATH所以你必须使用-p告诉它不要.IE:
sudo su -p
这种"令人讨厌的功能"可以防止你受到攻击.我说强制一个特定的$ PATH是一个功能,而不是一个bug ---它会让你写出一个程序的完整路径,这个程序在$ PATH之外. (46认同)
它不仅违反直觉,而且记录不正确.阅读sudo的手册页,并将配置与Fedora框进行比较,我认为应该保留路径.实际上,"sudo -V"甚至说"要保留的环境变量:PATH". (30认同)
是的,但这完全是违反直觉的.它可能比坏人更能欺骗好人. (28认同)
不要别名sudo; 请参阅@Jacob关于Defaults env_reset的回答. (7认同)
它很烦人.期.如果它可以让你被"sudo变得特洛伊",它会让你在没有它的情况下变成木马.授予,更难,但如果你是在正常用户的情况下从错误的地方运行代码,那么事情就已经够糟糕了. (6认同)
@JasonR.Coombs是的,文档广告侮辱了烦恼.这就是为什么我尊重openBSD来处理像代码这样的文档.那可能是一个阻塞的错误.在ubuntu上... (3认同)
此别名使用以root身份运行的未引用变量替换.(它也会导致你使用它运行的每个命令都有两个不必要的fork/execs)即使安全性在你的盒子上并不重要,这对我来说也是邪恶的.使用!secure_path和env_keep查看解决方案. (2认同)
小智.. 119
如果其他人在此处运行,并且想要禁用所有用户的所有路径变量更改.
使用以下命令访问您的sudoers文件:visudo
.您应该在某处看到以下行:
默认值为env_reset
你应该在下一行添加以下内容
默认值!secure_path
secure_path默认启用.此选项指定在sudoing时使$ PATH成为什么.感叹号禁用该功能.
这是 一个烦人的功能 sudo在许多发行版上的一个特性.
要在ubuntu上解决这个"问题",我在〜/ .bashrc中执行以下操作
alias sudo='sudo env PATH=$PATH'
请注意,上述内容适用于不重置$ PATH的命令.但是`su'重置它的$ PATH所以你必须使用-p告诉它不要.IE:
sudo su -p
如果其他人在此处运行,并且想要禁用所有用户的所有路径变量更改.
使用以下命令访问您的sudoers文件:visudo
.您应该在某处看到以下行:
默认值为env_reset
你应该在下一行添加以下内容
默认值!secure_path
secure_path默认启用.此选项指定在sudoing时使$ PATH成为什么.感叹号禁用该功能.
PATH
是一个环境变量,因此默认情况下由sudo重置.
您需要特殊权限才能执行此操作.
从 man sudo
-E The -E (preserve environment) option will override the env_reset option in sudoers(5)). It is only available when either the match- ing command has the SETENV tag or the setenv option is set in sudo- ers(5).
Environment variables to be set for the command may also be passed on the command line in the form of VAR=value, e.g. LD_LIBRARY_PATH=/usr/local/pkg/lib. Variables passed on the command line are subject to the same restrictions as normal environment vari- ables with one important exception. If the setenv option is set in sudoers, the command to be run has the SETENV tag set or the command matched is ALL, the user may set variables that would overwise be for- bidden. See sudoers(5) for more information.
用法示例:
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
man 5 sudoers : env_reset If set, sudo will reset the environment to only contain the LOGNAME, SHELL, USER, USERNAME and the SUDO_* vari- ables. Any variables in the caller's environment that match the env_keep and env_check lists are then added. The default contents of the env_keep and env_check lists are displayed when sudo is run by root with the -V option. If sudo was compiled with the SECURE_PATH option, its value will be used for the PATH environment variable. This flag is on by default.
因此可能需要检查是否已编译.
默认情况下,它是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}"
看起来这个bug已经存在了很长一段时间!以下是您可能会发现有用的一些错误参考(并且可能想要订阅/投票,提示,提示...):
Debian bug#85123("sudo:SECURE_PATH仍然无法覆盖")(从2001年开始!)
似乎Bug#20996仍然存在于此版本的sudo中.更改日志说它可以在运行时被覆盖,但我还没有发现如何.
他们提到在你的sudoers文件中放置这样的东西:
Defaults secure_path="/bin:/usr/bin:/usr/local/bin"
但是当我至少在Ubuntu 8.10中这样做时,它给了我这个错误:
visudo: unknown defaults entry `secure_path' referenced near line 10
Ubuntu bug#50797("用--with-secure-path构建的sudo有问题")
更糟糕的是,据我所知,在sudoers文件中重新指定secure_path是不可能的.因此,例如,如果您想让用户轻松访问/ opt下的某些内容,则必须重新编译sudo.
是.有需要可重写此"功能",而无需重新编译的方法.没有什么比安全偏执狂告诉你什么对你的环境最好,然后没有给你一个方法来关闭它更糟糕.
这真的很烦人.出于安全原因,默认情况下保持当前行为可能是明智的,但除了从源代码重新编译之外,应该有一种覆盖它的方法!很多人都需要PATH继承.我想知道为什么没有维护人员对它进行研究,这似乎很容易找到一个可接受的解决方案.
我像这样工作:
mv /usr/bin/sudo /usr/bin/sudo.orig然后创建一个包含以下内容的文件/ usr/bin/sudo:
#!/bin/bash /usr/bin/sudo.orig env PATH=$PATH "$@"然后你的常规sudo就像非安全路径sudo一样工作
Ubuntu bug#192651("sudo path is always reset")
鉴于此错误的副本最初是在2006年7月提交的,我不清楚无效的env_keep在运行多长时间.无论强迫用户使用上面列出的技巧的优点是什么,sudo和sudoers的手册页肯定应该反映出修改PATH的选项实际上是多余的这一事实.
修改文档以反映实际执行不会造成不稳定并且非常有用.
Ubuntu bug#226595("不可能保留/指定PATH")
我需要能够在PATH中运行带有其他非std二进制文件夹的sudo.已经将我的需求添加到/ etc/environment中,当我在sudo下运行它们时遇到错误的命令时,我感到很惊讶.....
我尝试了以下方法来解决这个问题:
使用"
sudo -E
"选项 - 不起作用.我现有的PATH仍然被sudo重置在/ etc/sudoers中将"
Defaults env_reset
" 更改为"Defaults !env_reset
"也无效(即使与sudo -E结合使用)在/ etc/sudoers中取消注释
env_reset
(例如"#Defaults env_reset
") - 也不起作用.添加'
Defaults env_keep += "PATH"
'到/ etc/sudoers - 也没有用.显然 - 尽管有man文档 - sudo完全是关于PATH的硬编码,并且不允许保留用户PATH的任何灵活性.非常烦人,因为我无法使用sudo在root权限下运行非默认软件.
这似乎对我有用
sudo -i
这取决于非sudo PATH
我认为让sudo重置PATH实际上是可取的:否则攻击者破坏了你的用户帐户可能会在用户的路径上放置各种工具的后门版本,并且在使用sudo时会执行它们.
(当然让sudo重置PATH并不是解决这些问题的完全解决方案,但它有帮助)
这确实是你使用时会发生的事情
Defaults env_reset
在/ etc/sudoers中没有使用exempt_group
或env_keep
.
这也很方便,因为您可以将仅对root(例如/sbin
and /usr/sbin
)有用的目录添加到sudo路径,而无需将它们添加到用户的路径.要指定sudo使用的路径:
Defaults secure_path="/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin"
现在使用来自业力存储库的sudo工作.我配置的详细信息:
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 restricted universe deb-src http://au.archive.ubuntu.com/ubuntu/ jaunty main restricted universe deb http://au.archive.ubuntu.com/ubuntu/ jaunty-updates main restricted universe deb-src http://au.archive.ubuntu.com/ubuntu/ jaunty-updates main restricted universe deb http://security.ubuntu.com/ubuntu jaunty-security main restricted universe deb-src http://security.ubuntu.com/ubuntu jaunty-security main restricted universe deb http://au.archive.ubuntu.com/ubuntu/ karmic main restricted universe deb-src http://au.archive.ubuntu.com/ubuntu/ karmic main restricted universe deb http://au.archive.ubuntu.com/ubuntu/ karmic-updates main restricted universe deb-src http://au.archive.ubuntu.com/ubuntu/ karmic-updates main restricted universe deb http://security.ubuntu.com/ubuntu karmic-security main restricted universe deb-src http://security.ubuntu.com/ubuntu karmic-security main restricted 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:~$
在不使用黑客的情况下最终解决这个问题真是太棒了.