sudo and secure-path

[Karlos Smith]

Jon Stanley wrote:
> On Tue, Nov 18, 2008 at 8:54 PM, Matthew Miller <mattdm at mattdm.org> wrote:
>
>   
>> Yes. The tab-completion thing working is a side-effect -- the more important
>> thing is no surprises. How about a compromise -- add /usr/local/sbin to the
>> secure path?
>>     
--secure-path wasn't added for security reasons as far as I can tell. 
It was added so people could type "sudo ifconfig" instead of "sudo
/sbin/ifconfig".

So as it stands, we are saving people from occasionally having to type
'/sbin/', and forcing others to *frequently* type '/usr/local/sbin/'.
That's not a fair trade-off.  But, I wouldn't complain if there were a
work around.

/usr/local/  isn't one of the paths I preserve across installs, so
adding /usr/local/sbin to the secure path wouldn't solve my problem
anyway (I make heavy use of ~/bin/).
>
> You can't be guaranteed that path is in fact secure. Lots of systems
> mount /usr/local from somewhere outside of their domain of control,
> and I don't want to blindly trust stuff in there.
>   
I thought the whole point of /usr/local was for *locally* installed
programs.

OK from FHS2.3:
"The /usr/local hierarchy is for use by the system administrator when
installing software locally. [...]It may be used for programs and data
that are shareable amongst a group of hosts, but not found in /usr." 

Seems odd to me.  However /usr/local/sbin, is no *less* secure than
/usr/sbin!
/usr/sbin "should" be sharable
/usr/local/bin "may" be sharable

And btw  /usr/local/sbin is in the default path for root in a default
install of Fedora, so it seems we already implicitly trust /usr/local/sbin.

Having said all that, I reiterate that adding /usr/local/sbin to the
secure-path, is a deficient workaround.
> Users have a PATH for a reason. Let them keep it.
>   
Exactly.  However, I see nothing wrong with *adding*  /sbin /usr/sbin
and /usr/local/sbin when sudoing to root.
I don't mind making things easier, that's what a computer is for, but
removing functionality from experienced users, to add ease to newer
users is a bad idea.

-- 
Karlos Smith
Red Hat Global Services
kasmith at redhat.com
+1 361 649-6255 c.