Description of problem: In an effort to make things easier for less experienced admins, sudo was recompiled with "--with-secure-path=/sbin:/bin:/usr/sbin:/usr/bin" https://bugzilla.redhat.com/show_bug.cgi?id=80215 *adding* /sbin /usr/sbin and /usr/local/sbin to the path when sudo'ing to the root user is one thing. *hardcoding* the path is bad form IMHO. I would settle for a configfile option, but I don't think that's the right thing. I have no problem with https://bugzilla.redhat.com/show_bug.cgi?id=80215#c5 and making something "just work" for less experienced admins, but removing the functionality that more experienced admins depend on is quite frustrating. I have some scripts that I allow non-privileged users to run through sudo without root's password, and suddenly this is now broken. As far as I can see there is no elegant solution for me. I can copy all the scripts to /usr/bin or retrain my users Version-Release number of selected component (if applicable): sudo-1.6.9p13-7.fc9.i386 How reproducible: Always. Steps to Reproduce: 1.users path includes /path/to/scripts/ 2.sudo is configured to allow users to run /path/to/scripts/somescript as root 3.`sudo somescript` Actual results: "sudo: somescript: command not found" Expected results: somescript should run with elevated privileges. Additional info: https://bugzilla.redhat.com/show_bug.cgi?id=80215 http://mailinglistarchive.com/fedora-devel-list@redhat.com/msg49858.html
Seconded. It annoyed me a lot after I installed F-10. I have a script in $HOME/bin and now I have to run it as sudo /home/user/bin/script instead of just sudo script.
Strongly in agreement.
*** Bug 472541 has been marked as a duplicate of this bug. ***
*** Bug 479115 has been marked as a duplicate of this bug. ***
sudo-1.6.9p17-3.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/sudo-1.6.9p17-3.fc10
Same update for f9: https://admin.fedoraproject.org/updates/sudo-1.6.9p13-8.fc9
sudo-1.6.9p17-4.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update sudo'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-0333
sudo-1.6.9p13-8.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing-newkey update sudo'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-0476
This bug is still unfixed in 1.6.9p17-4.fc10.
Workaround: alias sudo="sudo env PATH=$PATH"
Agreed, the new update doesn't fix this bug: [kylev@kylev-dt ~]$ rpm -q sudo sudo-1.6.9p17-4.fc10.i386 [kylev@kylev-dt ~]$ which sayhello.sh ~/bin/sayhello.sh [kylev@kylev-dt ~]$ sayhello.sh Hello [kylev@kylev-dt ~]$ sudo sayhello.sh sudo: sayhello.sh: command not found
Actually, the more I think about this, I agree with the current fix (which re-added /usr/local/bin to the sudo path). If you have programs that you want to be able to run under sudo and "trust", put them in /usr/local/bin. By its very nature, ~/bin is insecure, unsafe, and user controlled. If someone puts an ls or vim replacement (or typo varient) in a compromised user's ~/bin, they potentially get to elevate their privileges to root the first time that user sudo's. That's bad security. It may be slightly annoying, but I think it's the right call. Put trusted scripts and the like in /usr/local/bin .
> It may be slightly annoying, but I think it's the right call. Put trusted > scripts and the like in /usr/local/bin All my scripts are under "/mnt/data/scripts" and if i set for all users the PATH-Variable there i know what i do. It is impossible to put them under /usr/local/bin if you use x86_64 and i386 and want to rsync your own scripts
(In reply to comment #14) > All my scripts are under "/mnt/data/scripts" and if i set for all users the > PATH-Variable there i know what i do. It is impossible to put them under > /usr/local/bin if you use x86_64 and i386 and want to rsync your own scripts The restricted PATH is a pretty important part of the secure operation of sudo, and it won't be able to accommodate everyone's custom environments. Options include: - Write something to create symlinks from /usr/local/bin into your scripts directory. - Package your scripts into an RPM and drop them in nice places in the PATH (possibly even creating your own business-local YUM repo). - Experiment with the env_reset option in sudoers ("man 5 sudoers") and turn it off for certain users or groups. I still think leaving the PATH-cleaning default sudo settings in place is best for Fedora out of the box, and helps mitigate the risk of command spoofing.
FWIW, the solution of including /usr/local/bin in the path handles my use-case.
(In reply to comment #16) > FWIW, the solution of including /usr/local/bin in the path handles my use-case. This is not what the original bug report was about. It's an undocumented regression of functionality. There's nothing in the release notes about it, hence I request that the default be changed back to what it was or that it be prominently documented and that a way to set it back to allowing any path is provided.
To say it clear: It is idiotic to change such things If my user has sudo-permissions i i have a shell-script or anything else which needs root-permissions and i have set PATH to the location i know what i do "If something places ls in your path and you run sudo" is also idiotic If i make "su" without "su -" its the same and i hope that some crazy guy does not change this also - My PATH is my PATH, was my PATH and has to be my PATH - Thats the point- How crazy must anyone be to say its ok if "which bla.sh" says "yes there is a script" and sudo says after typing passowrt "no such file"?
sudo-1.6.9p13-8.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
sudo-1.6.9p17-4.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
Yes, the problem still persists, so please don't close this bug and don't pretend this update fixes it.
sudo-1.6.9p17-5.fc10 has still the problem. sudo does not allow me to call sudo command where command is in /usr/local/sbin/command and there is a line with allows to call /usr/local/sbin/command for me and /usr/local/sbin is in my path. The error is "command not found". I have to call sudo /usr/local/sbin/command then it works. This have worked some time ago - before Fedora 9 if i remember right. I think: If an explicit path is specified for an allowed program and this is in PATH and matches the program, then it should be allowed to call it without a full path.
So we've included /usr/local/bin, but not /usr/local/sbin in the SECUREPATH? by definition that doesn't make sense. scripts in /usr/local/bin should *not* need root access right? Looks like we've set secure path to "PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin" While by default users paths is ~ "/usr/local/bin:/usr/bin:/bin" and *root's* path is ~ "/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin" Do we really need three separate path orders? Since we've finally agreed that all three of /{s,}bin /usr/{s,}bin and /usr/local/{s,}bin are all *secure* paths, isn't the most intelligent ordering "/usr/local/{s,}bin:/usr/{s,}bin:/{s,}bin" With root (and sudo) having both */{s,}bin and non-privledged having only */bin?
(In reply to comment #15) > - Experiment with the env_reset option in sudoers ("man 5 sudoers") and turn it > off for certain users or groups. SECURE_PATH *overrides* env_keep for PATH!
shouldn't the compile time SECURE_PATH be a simple 'y|n', and a Secure_Path option be added to /etc/sudoers? The only argument against that is that it allows stupid admins to do stupid things. Are we going to start officially trying to outsmart our admins? There are enough use cases (such as comment #14) that we *cannot* claim that changing the Secure_Path is a bad idea. But setting a sane default *and allowing admins to change the default* (with warnings as necessary), is the only sane course of action where we are not insulting our userbase. Having said this, the current change solves my immediate issue.
I'm definitely a "less-experienced admin"; I run my own box, I'm the only user on it, and I only touch it when it breaks. And 1.6.9p13-8 is broken for me on F9. I think #23 sums it up. /usr/local/bin comes before /usr/bin when I'm a normal user, and after it when I'm sudo'ing. That breaks.. well, lots of things, I'm sure. It certainly breaks anything in /usr/local/bin that's intended to override the rpm-provided binaries. F'rinstance, I have ack-1.86 installed in /usr/local/bin - and by extension in /usr/local/lib/perl5. F9 repositories only had 1.82 last time I updated, so that's what's in /usr/bin. When I'm non-root, it works great. When I'm sudo-ed, I get: ack: Program/library version mismatch /usr/bin/ack is 1.82 /usr/local/lib/perl5/site_perl/5.10.0/App/Ack.pm is 1.86 Obviously, in this case I could just remove the ack RPM. But there are plenty of other times I use /usr/local/bin to override /usr/bin, and I can't remove the relevant RPM due to dependencies; I'm sure I'm not alone. I don't want to have to create my own pseudo-RPMs to do that.
Jay, if you want to use a special version of a program you installed in /usr/local it would be the best if you give it another name (e.g. perl-local or something like that) and use that name in your special programs that need that version. Or use the full path (like /usr/local/bin/perl) to ensure that the right program will be used. With the same name it depends on the order in PATH which program is called - and you only can be sure about it if you set PATH before calling programs. If /usr/local/{,s}bin would be in path before /usr/{,s}bin then if you install programs with the same name as the "system" programs in /usr/local/{,s}bin they will be found and used instead of the system programs. This may be right for your own (personally installed) programs, but depending on the version there may be incompatiblities with other system programs that may eventually not work as expected. To for system programs and services - and the user root as root mostly start system programs - it should be ensured that the system programs work together right and the right "system" versions will be found. So default path should contain the systems paths /{s,}bin and /usr/{s,}bin before nonsystem-path /usr/local/{,s}bin. So I partly agree with #23 but path should be ordered like "/{s,}bin:/usr/{s,}bin:/usr/local/{s,}bin". Please use another program name or a full path or set PATH before calling a specific application to ensure that your applications work as you intend it, but leave the default for standard programs on the default. Please also regard that /usr/local can be shared among systems with the same operating system, for example over nfs. (See Linux filesystem Standard 1.2 ( e.g. http://linux.tnc.edu.tw/techdoc/linux-books/rute/node38.html ) part 35.4.9.1: "It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr.") About your perl problem: Look at the output of 'perl -v". At the end of the output you will see a line with '@INC:' followed by perl search paths. If you install an incompatible perl version in /usr/local then you should not use one of the listed paths because it may break system programs (they may use perl - and will fall to the error you have listed). Use other directories and / or prefixes for your own (incompatible) programs (specify them at compiletime).
Edgar - Shouldn't that be equally true for regular users and root, though? I can see an argument for "/usr/local/bin first" (my argument!), and I can see an argument for "/usr/local/bin last" (your argument - system compatibility). But I can't see an argument for "/usr/local/bin first for default users, /usr/bin first for root". And FWIW, it looks like the "/usr/local/bin first" argument won in #458176. And I do set PATH myself before calling programs - or at least I thought I did, until this change. In fact, I went through quite an ordeal getting my Mac and Fedora boxes to use the same basic .zshrc; the env_reset change coincided with a sudo bug that broke "env_keep += path", which coincided with Apple's code freeze for Leopard. So here I had a four-way-working path setup, and along comes sudo1.6.9p13-8 to break it. My ack problem isn't a Perl version problem; the trouble is that sudo now puts /usr/local/bin after /usr/bin, but of course it doesn't change perl's @INC path, which has /usr/local/lib/perl5/site_perl/5.10.0 before /usr/lib/perl5/vendor_perl/5.10.0. (Which seems another argument for keeping /usr/local/bin before /usr/bin...) To clarify, the behavior I'm saying is buggy under F9/sudo 1.6.9p13-8 is this: % sudo -s # echo "echo local" > /usr/local/bin/bug471603 # echo "echo system" > /usr/bin/bug471603 # chmod a+x /usr/local/bin/bug471603 /usr/bin/bug471603 # rehash # bug471603 system # exit % bug471603 local
Hi, I've ported the sudo-1.6.x patches to sudo-1.7.x and after I'm done with testing I'll push the new version (sudo-1.7.1-1) to updates-testing (for F-11). The secure_path Defaults option is available again in 1.7.x. Sorry for the delay. The rpms are currently available here: http://koji.fedoraproject.org/koji/taskinfo?taskID=1333391
Hi Daniel, I installed your new build package on my F10 x86_64 system and set secure_path in /etc/sudoers: Defaults secure_path = /bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin I tested my application as described in comment #22 and now sudo command works again! Thanks much! If the packages passes fedora testing phase would it be possible to release it also to F-10 and F-9? At least on F-10 there was no missing dependency.
(In reply to comment #30) Hi Edgar, thanks for the feedback. > If the packages passes fedora testing phase would it be possible to release it > also to F-10 and F-9? At least on F-10 there was no missing dependency. Yes, I think that it can be pushed at least to F-10 too. Here are the builds: f10: http://koji.fedoraproject.org/koji/taskinfo?taskID=1333483 f9: http://koji.fedoraproject.org/koji/taskinfo?taskID=1333488
Yep, works for me on F9/x86-64, with Defaults secure_path = /usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin Thanks!
sudo-1.7.1-2.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/sudo-1.7.1-2.fc10
sudo-1.7.1-2.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update sudo'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-4874
sudo-1.7.1-2.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.