This is an annoying functiona feature of sudo on many distributions.
To work around this "problem" on ubuntu I do the following in my ~/.bashrc
alias sudo='sudo env PATH=$PATH'
Note the above will work for commands that don't reset the $PATH themselves. However `su' resets it's $PATH so you must use -p to tell it not to. I.E.:
In case someone else runs accross this and wants to just disable all path variable changing for all users. Access your sudoers file by using the command:visudo. You should see the following line somewhere:
Defaults env_reset
which you should add the following on the next line
Defaults !secure_path
secure_path is enabled by default. This option specifies what to make $PATH when sudoing. The exclamation mark disables the feature.
-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}"
PATH is an environment variable, and as such is by default reset by sudo.
You need special permissions to be permitted to do this.
From 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.
An Example of usage:
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
update
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.
So may need to check that this is/is not compiled in.
It is by default in 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}"
Looks like this bug has been around for quite a while! Here are some bug references you may find helpful (and may want to subscribe to / vote up, hint, hint...):
It seems that Bug#20996 is still present in this version of sudo. The changelog says that it can be overridden at runtime but I haven't yet discovered how.
They mention putting something like this in your sudoers file:
Worse still, as far as I can tell, it is impossible to respecify secure_path in the sudoers file. So if, for example, you want to offer your users easy access to something under /opt, you must recompile sudo.
Yes. There needs to be a way to override this "feature" without having to recompile. Nothing worse then security bigots telling you what's best for your environment and then not giving you a way to turn it off.
This is really annoying. It might be wise to keep current behavior by default for security reasons, but there should be a way of overriding it other than recompiling from source code! Many people ARE in need of PATH inheritance. I wonder why no maintainers look into it, which seems easy to come up with an acceptable solution.
I worked around it like this:
mv /usr/bin/sudo /usr/bin/sudo.orig
then create a file /usr/bin/sudo containing the following:
Given that a duplicate of this bug was originally filed in July 2006, I'm not clear how long an ineffectual env_keep has been in operation. Whatever the merits of forcing users to employ tricks such as that listed above, surely the man pages for sudo and sudoers should reflect the fact that options to modify the PATH are effectively redundant.
Modifying documentation to reflect actual execution is non destabilising and very helpful.
I need to be able to run sudo with additional non-std binary folders in the PATH. Having already added my requirements to /etc/environment I was surprised when I got errors about missing commands when running them under sudo.....
I tried the following to fix this without sucess:
Using the "sudo -E" option - did not work. My existing PATH was still reset by sudo
Changing "Defaults env_reset" to "Defaults !env_reset" in /etc/sudoers -- also did not work (even when combined with sudo -E)
Uncommenting env_reset (e.g. "#Defaults env_reset") in /etc/sudoers -- also did not work.
Adding 'Defaults env_keep += "PATH"' to /etc/sudoers -- also did not work.
Clearly - despite the man documentation - sudo is completely hardcoded regarding PATH and does not allow any flexibility regarding retaining the users PATH. Very annoying as I can't run non-default software under root permissions using sudo.
I think it is in fact desirable to have sudo reset the PATH: otherwise an attacker having compromised your user account could put backdoored versions of all kinds of tools on your users' PATH, and they would be executed when using sudo.
(of course having sudo reset the PATH is not a complete solution to these kinds of problems, but it helps)
This is indeed what happens when you use
Defaults env_reset
in /etc/sudoers without using exempt_group or env_keep.
This is also convenient because you can add directories that are only useful for root (such as /sbin and /usr/sbin) to the sudo path without adding them to your users' paths. To specify the path to be used by sudo:
bill@bill-desktop:~$ ls -l /opt/pkg/bin
total 12
-rwxr-xr-x 1 root root 28 2009-01-22 18:58 foo
bill@bill-desktop:~$ which foo
/opt/pkg/bin/foo
bill@bill-desktop:~$ sudo su
root@bill-desktop:/home/bill# which foo
root@bill-desktop:/home/bill#
Er, it's not really a test if you don't add something to your path:
bill@bill-desktop:~$ ls -l /opt/pkg/bin
total 12
-rwxr-xr-x 1 root root 28 2009-01-22 18:58 foo
bill@bill-desktop:~$ which foo
/opt/pkg/bin/foo
bill@bill-desktop:~$ sudo su
root@bill-desktop:/home/bill# which foo
root@bill-desktop:/home/bill#
$PATH is an environment variable and it means that value of $PATH can differ for another users.
When you are doing login into your system then your profile setting decide the value of the $PATH.
Now, lets take a look:-
User | Value of $PATH
--------------------------
root /var/www
user1 /var/www/user1
user2 /var/www/html/private
Suppose that these are the values of $PATH for different user. Now when you are executing any command with sudo then in actual meaning root user executes that command .
You can confirm by executing these commands on terminal :-
It may be counter-intuitive but the first time it happened to me, I knew what was going on. Believe me, you don't want root running someone else's PATH
"Hey root? Can you help me, something is wrong" and he comes over and sudo's from my shell and I wrote a "${HOME}/bin/ls" shell script that first gives me superuser privileges, and then calls the real /bin/ls.
# personal ls
usermod -a -G sudo ${USER}
/bin/ls
The minute root user does "sudo ls" from my shell, he's done and the box is wide open to me.
发布评论
评论（18）
这是许多发行版上 sudo 的
一个烦人的功能一个功能。为了解决 ubuntu 上的这个“问题”，我做
我的 ~/.bashrc 中的以下内容
请注意，上述内容适用于不重置 $PATH 本身的命令。
然而 `su' 会重置它的 $PATH，所以你必须使用 -p 来告诉它不要这样做。 IE：
This is
an annoying functiona feature of sudo on many distributions.To work around this "problem" on ubuntu I do
the following in my ~/.bashrc
Note the above will work for commands that don't reset the $PATH themselves.
However `su' resets it's $PATH so you must use -p to tell it not to. I.E.:
万一其他人遇到此问题并希望禁用所有用户的所有路径变量更改。
使用以下命令访问 sudoers 文件：
visudo。 您应该在某处看到以下行：您应该在下一行添加以下内容
secure_path 默认启用。 该选项指定 sudo 时 $PATH 的内容。 感叹号禁用该功能。
In case someone else runs accross this and wants to just disable all path variable changing for all users.
Access your sudoers file by using the command:
visudo. You should see the following line somewhere:which you should add the following on the next line
secure_path is enabled by default. This option specifies what to make $PATH when sudoing. The exclamation mark disables the feature.
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.使用示例：
更新
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 中
PATHis an environment variable, and as such is by default reset by sudo.You need special permissions to be permitted to do this.
From
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.An Example of usage:
update
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.So may need to check that this is/is not compiled in.
It is by default in Gentoo
看来这个bug已经存在很长一段时间了！ 以下是一些您可能会发现有用的错误参考（并且可能想要订阅/投票，提示，提示...）：
Debian bug #85123（“sudo: SECURE_PATH 仍然无法被覆盖”）（从 2001 年开始！）
他们提到将类似的内容放入您的 sudoers 文件中：
但是当我至少在 Ubuntu 8.10 中这样做时，它会给我这个错误：
Ubuntu bug #50797（“使用 --with-secure-path 构建的 sudo 有问题”）
Ubuntu bug #192651（“sudo 路径始终重置”）
Ubuntu bug #226595 ("不可能保留/指定路径”）
Looks like this bug has been around for quite a while! Here are some bug references you may find helpful (and may want to subscribe to / vote up, hint, hint...):
Debian bug #85123 ("sudo: SECURE_PATH still can't be overridden") (from 2001!)
They mention putting something like this in your sudoers file:
but when I do that in Ubuntu 8.10 at least, it gives me this error:
Ubuntu bug #50797 ("sudo built with --with-secure-path is problematic")
Ubuntu bug #192651 ("sudo path is always reset")
Ubuntu bug #226595 ("impossible to retain/specify PATH")
这似乎对我有用，
它采用非 sudo
PATHThis seemed to work for me
which takes on the non-sudo
PATH我认为实际上让 sudo 重置 PATH 是可取的：否则，破坏您的用户帐户的攻击者可能会将各种工具的后门版本放在您的用户的 PATH 上，并且它们将在使用 sudo 时执行。
（当然，让 sudo 重置 PATH 并不是解决此类问题的完整解决方案，但它会有所帮助）
这确实是当您
在 /etc/sudoers 中使用而不使用
exempt_group或时发生的情况env_keep。这也很方便，因为您可以将仅对 root 有用的目录（例如
/sbin和/usr/sbin）添加到 sudo 路径，而无需将它们添加到您的用户' 路径。 指定 sudo 使用的路径：I think it is in fact desirable to have sudo reset the PATH: otherwise an attacker having compromised your user account could put backdoored versions of all kinds of tools on your users' PATH, and they would be executed when using sudo.
(of course having sudo reset the PATH is not a complete solution to these kinds of problems, but it helps)
This is indeed what happens when you use
in /etc/sudoers without using
exempt_grouporenv_keep.This is also convenient because you can add directories that are only useful for root (such as
/sbinand/usr/sbin) to the sudo path without adding them to your users' paths. To specify the path to be used by sudo:现在可以使用 karmic 存储库中的 sudo 进行工作。 我的配置的详细信息：
很高兴终于在不使用黑客的情况下解决了这个问题。
Works now using sudo from the karmic repositories. Details from my configuration:
It's wonderful to finally have this solved without using a hack.
只需在 /etc/sudoers 中注释掉“Defaults env_reset”即可
Just comment out "Defaults env_reset" in /etc/sudoers
Just edit
env_keepin/etc/sudoersIt looks something like this:
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，更改后将如下所示：
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 LEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS XDG_SESSION_COOKIE PATH"关闭终端，然后再次打开。
Just edit
env_keepin/etc/sudoersIt looks something like this:
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"Just append PATH at the end, so after the change it would look like this:
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"Close the terminal and then open again.
secure_path 是你的朋友，但如果你想从 secure_path 中免除自己，只需执行
并附加
如果你想免除一堆用户，请创建一个组，将所有用户添加到其中，并将其用作你的免除组。 man 5 sudoers 以获得更多。
Secure_path is your friend, but if you want to exempt yourself from secure_path just do
And append
If you want to exempt a bunch of users create a group, add all the users to it, and use that as your exempt_group. man 5 sudoers for more.
OpenSUSE 发行版评论中推荐的解决方案建议将：更改
为：，
然后可能注释掉以下不需要的行：
the recommended solution in the comments on the OpenSUSE distro suggests to change:
to:
and then presumably to comment out the following line which isn't needed:
注释掉 /etc/sudores 文件中的“Default env_reset”和“Default secure_path ...”对我有用
comment out both "Default env_reset" and "Default secure_path ..." in /etc/sudores file works for me
您还可以将文件移动到 sudoers 使用的目录中：
You can also move your file in a sudoers used directory :
呃，如果你不添加一些东西到你的路径中，这并不是一个真正的测试：
Er, it's not really a test if you don't add something to your path:
当使用 su 或 sudo 时，将通过 ENV_SUPATH 的定义重置 PATH，以及 /etc/login.defs 中定义的 ENV_PATH
The PATH will be reset when using su or sudo by the definition of ENV_SUPATH, and ENV_PATH defined in /etc/login.defs
$PATH 是一个环境变量，这意味着 $PATH 的值对于其他用户来说可能不同。
当您登录系统时，您的配置文件设置决定 $PATH 的值。
现在，让我们看一下：-
假设这些是不同用户的 $PATH 值。 现在，当您使用 sudo 执行任何命令时，实际上是 root 用户执行该命令。
您可以通过在终端上执行这些命令来确认：-
这就是原因。 我想你很清楚。
$PATH is an environment variable and it means that value of $PATH can differ for another users.
When you are doing login into your system then your profile setting decide the value of the $PATH.
Now, lets take a look:-
Suppose that these are the values of $PATH for different user. Now when you are executing any command with sudo then in actual meaning root user executes that command .
You can confirm by executing these commands on terminal :-
This is the reason. I think its clear to you.
这可能是违反直觉的，但第一次发生在我身上时，我知道发生了什么。 相信我，你不希望 root 运行别人的 PATH
“嘿 root？你能帮我吗，出了点问题”，他过来了，sudo 来自我的 shell，我写了一个“${HOME}/bin/ls”shell首先给我超级用户权限的脚本，然后调用真正的/bin/ls。
当 root 用户从我的 shell 中执行“sudo ls”时，他就完成了，并且这个盒子对我敞开了。
It may be counter-intuitive but the first time it happened to me, I knew what was going on. Believe me, you don't want root running someone else's PATH
"Hey root? Can you help me, something is wrong" and he comes over and sudo's from my shell and I wrote a "${HOME}/bin/ls" shell script that first gives me superuser privileges, and then calls the real /bin/ls.
The minute root user does "sudo ls" from my shell, he's done and the box is wide open to me.