sudo and secure-path
Jon Stanley wrote:
> On Tue, Nov 18, 2008 at 8:54 PM, Matthew Miller <firstname.lastname@example.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
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
/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
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 "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.
Red Hat Global Services
+1 361 649-6255 c.
fedora-devel-list mailing list