Directory structures in the future and other things I want.

[David Mansfield]

On Thu, 2008-03-27 at 17:53 -0600, Stephen John Smoogen wrote:
> 2008/3/27 Jeff Spaleta <jspaleta at gmail.com>:
> >
> >
> > 2008/3/27 Jesse Keating <jkeating at redhat.com>:
> >
> > >
> > >
> > > Again, this argument is bunk.  If they're not supposed to be ran by
> > > normal users, hiding them behind a path is no form of security.  One can
> > > just run the full path to it.  If they're not supposed to be ran by
> > > users, they should have correct permissions on them, or they should
> > > check EUID of the caller before doing anything.
> > >
> >
> >
> > The question is, do we have programs down the sbins that make the wrong
> > assumption about path segregation equalling protection?  And if so, how
> > many?  The obvious ones to me that need scrutiny are the executables that
> > are setuid root.  Do we need to take some extra care about those setuid'd
> > executables?
> >
> 
> Not that I have run into.. the main thing is you need to make the path
> in the right order:
> 
> /bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/local/sbin.

Are you aware that that is not the same root's path, and the whole idea
was to take away the distinction of 'this program works like foo if I am
root, but bar if I'm a user'...  And also, the 'su -' works and 'su'
doesn't problem.  And the path with 'su -' is:

(some kerberos etc. garbage stripped out):

/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

It seems like your suggestion at least has the following problems:

* /usr/local/[s]bin needs to come before anything
* the 's' variants should come before the non-s variants
* console-helper should be fixed if it's so broken as to require the
path order to be different for different classes of users to work
properly, or simply, have console-helper drop the /usr/sbin component
and move it to /usr/libexec which is the normal convention.

The first point is definitely true, the second two are only possible
true ;-)

David