Bug 80215 - include /sbin and /usr/sbin in sudo secure path
Summary: include /sbin and /usr/sbin in sudo secure path
Alias: None
Product: Fedora
Classification: Fedora
Component: sudo
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Peter Vrabec
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2002-12-22 16:18 UTC by Matthew Miller
Modified: 2013-01-10 03:37 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2008-05-13 13:01:58 UTC
Type: ---

Attachments (Terms of Use)

Description Matthew Miller 2002-12-22 16:18:09 UTC
The default sudo path is quite limited and seemingly irrational given the
purpose of the program. I suggest adding something like


to the configure statement in the spec file.

That way, you can do things like "sudo service foo start".

Comment 1 Thomas Woerner 2003-01-02 11:29:25 UTC
Excerpt from the man page of sudo: "sudo â execute a command as another user". 

This can be any user. Therefore it does not make sense to overwrite the users
path environment variable with a fixed value, which is reasonable only for the
user root. The default behavior is to leave the users path untouched.

If you want to have /sbin etc. in your path, then add it to your normal user
path. You will have this path after calling sudo, too.

You can also use "sudo /sbin/service foo start".

Comment 2 Matthew Miller 2003-01-02 15:23:07 UTC
On the contrary -- it makes a *lot* of sense for there to be a fixed path, since
it reduces the possiblity of surprises when running a command as another user.
Since 90% of the use of this program is to run things as root, adding the sbin
directories to the path seems like a good idea. 

Note that this doesn't take any hacking -- the sudo maintainers have
conveniently left a "--with-secure-path" configure option.

Obviously "sudo /sbin/service foo start" is a possibility, but the addition of
those slashes and the extra directory name is significant overhead when
explaining what to do to someone else -- as I have to do a lot. It's even worse
when it's "sudo /usr/sbin/someprogram -someflags someoptions". Sure, end-users
should learn to understand the unix directory structure, but when they're
working to get a problem solved isn't necessarily the best time to hit them with it.

I won't reopen this on you since it's obviously your call, but I still think
changing it would be a good idea.

Comment 3 Matthew Miller 2008-04-23 18:26:36 UTC
I'm going to reopen this, as it periodically comes up, as it just did on the
Fedora Devel mailing list.

Comment 4 Matthew Miller 2008-04-23 18:35:00 UTC
As times have changed, I suggest a much more minimal securepath:


and anything else arguably *should* require a full pathname to be given.

Comment 5 Jesse Keating 2008-04-23 18:40:45 UTC
Yes, I'd really like to see this done.  If you feel that munging for every user
is bad, then work with upstream to add another option so that the path change is
only done when the sudo "to" user is root, and leave the path alone for other
users.  But that can be worked on in the background while improving the
usability of users who use sudo for root level tasks (which is the primary use).
 This will go a good ways toward lowering the frustration level when using

Comment 6 Axel Thimm 2008-04-23 19:10:24 UTC
Maybe it's worth exploring sudo -i further. It reminds a bit of su's '-' and
already does 99% of what it should do, it only chokes on

sudo -i <command>

being passed as $SHELL <command>, e.g. <command> needs to be a shell script.
Instead sudo could be changed to interprete

sudo -i <command> as invoking the target user's shell as $SHELL -c "<command>"

Comment 7 Jonathan Kamens 2008-05-23 17:06:24 UTC
FWIW, I think is a sucky, backward-incompatible change.

Making it something that the admin can configure in sudoers is one thing.  
Forcing it on absolutely everyone who uses sudo is quite another.  I don't like 
this behavior, it's not appropriate on my home machine, and it's going to be a 
royal pain in the ass for me and I suspect for many other people as well.  
There are a *ton* of programs I keep in ~/bin and ~/scripts, which are in my 
PATH, which I often need to use as root with sudo.

Comment 8 Matthew Miller 2008-05-23 17:29:45 UTC
Adding /usr/local/sbin to the secure path might be a compromise option that
would allow for more local control.

Comment 9 Ian Collier 2008-11-07 11:46:53 UTC
This change has recently appeared in updates-testing for F9 which I guess
means that people will start seeing it in their updates in the near future.

Count me in agreement with comment 7.  This should be a setting in the
/etc/sudoers file, not a something that is compiled in.

But never mind - I can script around it I guess.

Comment 10 Mikel Ward 2008-11-22 00:24:46 UTC
Is this what just broke my sudo?

I run sudo extdns as myself, which should find /home/mward/bin/extdns.

Since I applied the latest updates, I now get
$ sudo extdns
sudo: extdns: command not found

Comment 11 Mikel Ward 2008-11-22 00:28:48 UTC
Almost certainly it is:

$ cat checkpath

echo $PATH
$ ./checkpath
$ sudo ./checkpath

Also note that I removed the reset_env stuff from sudoers, since that was also really annoying (it nuked EDITOR, and some others I wanted).  All it contains is a couple of user and group specifications.

And why did this change get introduced to Fedora 9?

Comment 12 Mikel Ward 2008-11-22 00:56:13 UTC
This is completely the wrong change anyway.  The "sudo sanity" project for F10 was supposed to add /sbin and /usr/sbin to all users' PATHs via /etc/profile, not by touching (and breaking) sudo.


Comment 13 Matthew Miller 2008-11-22 01:55:09 UTC
re comment #10

If you're running commands in your own home directory via sudo, why not just put them in ~/sbin and create aliases or commands in ~/bin that automatically run them with sudo plus the full path?

re comment #11 -- instead of removing the environment-setting stuff, I strongly suggest configuring it to preserve the ones you want to keep. Otherwise, nasty things can be done.

re comment #12 -- this was part of the original sbin sanity proposal. The /sbin /usr/sbin mess ended up getting implemented as well. *That* seems like insanity to me, since it totally pollutes the namespace for tab completion in normal use. But ah well.

Comment 14 Mikel Ward 2008-11-22 03:19:54 UTC
> why not just put them in ~/sbin and create aliases?

Why?  The old way worked fine?

> instead of removing the environment-setting stuff..., I strongly
suggest configuring it to preserve the ones you want to keep. Otherwise, nasty
things can be done.

Again, why?

What kinds of problems are you referring to?

> The /sbin /usr/sbin mess ... it totally pollutes the namespace for tab completion

I have long had /sbin and /usr/sbin in my non-privileged user's PATH, and I never found it to be a problem.

In my view, sudo is for running commands exactly as I would run them but with higher privileges.  It means I get my own aliases, my own keybindings, my own value of EDITOR, my own SSH agent, etc, etc, .

If I want to run commands as root, there is "sudo su -" and "sudo -i", but the need for that has never arisen.

Comment 15 Ademar Reis 2009-08-13 18:34:40 UTC
Just my 2 cents:

I expect sudo to work mostly as described in the end of comment #14 and totally agree that sudo shouldn't be compiled with a hardcoded and non-changeable PATH.

For example, I have some development tools installed in /opt/ which I need to run via sudo and it came as a big surprise to me that I can't do it anymore... Specially because the option --with-secure-path is one of the less documented features of sudo.

What's the problem in having a conservative sudoers default file and let the admin finetune it (including adding PATH to keep_env) if needed?

Comment 16 Matthew Miller 2009-08-13 18:40:50 UTC
> /opt/ which I need to
run via sudo and it came as a big surprise to me that I can't do it anymore

Sure you can. You just need to provide the path explicitly, so there's no surprises.

Comment 17 Ademar Reis 2009-08-13 19:02:48 UTC
Which is anything but practical... but anyway, I now have a wrapper to workaround it:

set -e
CMD=$(which $1)
exec /usr/bin/sudo PATH=$PATH $CMD ${@:2}

(not perfect, but works in my common scenarios :-)

Comment 18 Jonathan Kamens 2009-08-13 19:23:28 UTC
(In reply to comment #16)
> You just need to provide the path explicitly, so there's no surprises.  

Hogwash.  The "surprises" are that people expect "sudo command" to behave the same as "command", just as a different user.  People do not expect "sudo command" to fail because "command" happens to be in a search path location that the package maintainers have presumptuously decided is not "secure enough."  People do not expect the package maintainers to make something like this completely unconfigurable even for people on private single-user systems who have worked in computer security for over two decades and know a thing or two about what is and isn't secure.

This is nothing more than annoying fake security.  It's a silly change, and it should be undone.

You want to have a paranoid default configuration?  Fine, keep your paranoid default configuration.  But let me override it in /etc/sudoers if I know what I'm doing, which I most assuredly do.

Comment 19 Matthew Miller 2009-08-13 19:27:33 UTC
The suggestion that this should be configurable in sudoers seems reasonable; once that change is upstream we could move the configuration option here from compile time to the sudoers file.

But this bug entry really isn't the place for extended discussion.

Comment 20 Ademar Reis 2009-08-13 19:47:08 UTC
The option is "secure_path", which combined with the already in place "reset_env" should be enough to reset the PATH by default.

Just adding to sudoers the following line should do the trick:

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

Should I open another ticket for this?

Comment 21 Matthew Miller 2009-08-13 20:00:48 UTC
Interesting — as you can see from the timeline of this bug, the original suggestion was from seven years ago. I actually looked in the Changelog to see if anything had changed -- I should have looked at the man page (or the source).

The "except_group" option also provides some interesting flexibility.

So yeah, please open a new bug, something along time lines of: "move secure_path from compile-time option to sudoers file". Thanks.

Comment 22 Ademar Reis 2009-08-13 21:05:53 UTC
Done, bug #517428


Comment 23 Dariusz 2010-09-15 16:06:52 UTC
For sercure path to work on RH4 or RH5 you need to add following to /etc/sudoers

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

Note You need to log in before you can comment on or make changes to this bug.