Jon Stanley wrote: > On Tue, Nov 18, 2008 at 8:54 PM, Matthew Miller <mattdm@xxxxxxxxxx> 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@xxxxxxxxxx +1 361 649-6255 c. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
