The default sudo path is quite limited and seemingly irrational given the purpose of the program. I suggest adding something like --with-secure-path=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin to the configure statement in the spec file. That way, you can do things like "sudo service foo start".
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".
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.
I'm going to reopen this, as it periodically comes up, as it just did on the Fedora Devel mailing list.
As times have changed, I suggest a much more minimal securepath: --with-secure-path=/sbin:/bin:/usr/sbin:/usr/bin and anything else arguably *should* require a full pathname to be given.
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 Fedora/RHEL.
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>"
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.
Adding /usr/local/sbin to the secure path might be a compromise option that would allow for more local control.
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.
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
Almost certainly it is: $ cat checkpath #!/bin/sh echo $PATH $ ./checkpath /opt/opsutils/bin:/home/mward/bin:/usr/local/bin:/usr/kerberos/bin:/usr/lib/qt-3.3/bin:/usr/lib/ccache:/usr/bin:/bin:/usr/java/latest/bin:/usr/java/latest/bin:/usr/java/latest/bin:/usr/sbin:/sbin:. $ sudo ./checkpath /sbin:/bin:/usr/sbin:/usr/bin 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?
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. http://fedoraproject.org/wiki/Features/SbinSanity
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.
> 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.
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?
> /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.
Which is anything but practical... but anyway, I now have a wrapper to workaround it: #!/bin/bash set -e CMD=$(which $1) exec /usr/bin/sudo PATH=$PATH $CMD ${@:2} (not perfect, but works in my common scenarios :-)
(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.
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.
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?
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.
Done, bug #517428 Thanks.
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"