Bug 517428 - move secure_path from compile-time option to sudoers file
Summary: move secure_path from compile-time option to sudoers file
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: sudo
Version: 12
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Daniel Kopeček
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-08-13 21:05 UTC by Ademar Reis
Modified: 2011-08-10 20:52 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-01-07 13:36:20 UTC


Attachments (Terms of Use)

Description Ademar Reis 2009-08-13 21:05:20 UTC
The current package currently sets the default path via configure --with-secure-path=... But this compile-time flag doesn't allow admins to enable different PATHs via /etc/sudoers.

The package should instead provide a default configuration file with a sane/safe PATH but allow changes as needed. A combination of secure_path and reset_env should be enough for that.

See discussion on bug #80125

Comment 1 Mikel Ward 2009-08-13 22:58:30 UTC
sudo stopped finding programs in $PATH due to a change in Fedora 10 (bug 80215).

This bug report is about fixing that.  I am obviously in favor.

Comment 2 Daniel Kopeček 2009-08-20 11:19:33 UTC
See discussion on bug #471603

Comment 3 Jonathan Kamens 2009-08-20 11:29:11 UTC
Matthew Miller seems to disagree.

MUST WE KEEP HAVING THIS SAME ARGUMENT OVER AND OVER AND OVER AGAIN?!  Sheesh!

If you want to create a default configuration in /etc/sudoers that removes non-standards directories from the search path, so that sudo is maximally secure by default, then great, fine, I think that's a jolly good idea.

BUT THERE IS NO JUSTIFICATION WHATSOEVER FOR MAKING THAT A COMPILE-TIME OPTION THAT CANNOT BE OVERRIDDEN IN THE CONFIGURATION FILE.

As at least one comment in bug 471603 noted, it is not the job of the people  building and releasing Fedora RPMs to prevent admins from consciously doing things that reduce the paranoia level, if they understand what they are doing.  So put a big honkin' comment above the secure_path setting in /etc/sudoers and warn the admin about what it means to change it, but LET THE ADMIN CHANGE IT IF S/HE KNOWS WHAT S/HE IS DOING, dammit!

For heaven's sake, there are COUNTLESS ways I could compromise my system's security with trivial configuration changes.  For us to be arguing about this one is mind-bogglingly absurd.

It is just unbelievable that we are still arguing about this.

Comment 4 Daniel Kopeček 2009-08-20 13:14:19 UTC
Ok, done.

http://koji.fedoraproject.org/koji/buildinfo?buildID=128052

Comment 5 Eric Paris 2009-08-23 19:24:48 UTC
something recently cause my rawhide machine to not have any /sbin entries in the PATH when I sudo -s.  Is that this bug?  Where am I supposed to set a sane default path now?

Comment 6 Eric Paris 2009-08-23 19:36:22 UTC
well, this bug was almost certainly the cause, and it sucks to break people like me, but I think it's for the better.  My problem is that I had edited my sudoers file so the new one which set the defaults secure_patch was created as a .rpmnew file.  When I added it by hand to my sudoers file things seem reasonable again.

Can I suggest a release note for this BZ?

Comment 7 Bug Zapper 2009-11-16 11:26:09 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 8 Ademar Reis 2009-11-30 17:39:45 UTC
This bug was fixed back in August:

* Thu Aug 20 2009 Daniel Kopecek <dkopecek@redhat.com> 1.7.1-6
- moved secure_path from compile-time option to sudoers file (#517428) 

I can confirm things are working in F12: secure_path, env_keep and env_reset (from /etc/sudoers) can be used as expected.

Comment 9 Matt Castelein 2011-08-10 20:52:58 UTC
Was the man page for SUDOERS(5) ever updated to reflect this change?


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