On Thu, 2008-03-27 at 17:53 -0600, Stephen John Smoogen wrote: > 2008/3/27 Jeff Spaleta <jspaleta@xxxxxxxxx>: > > > > > > 2008/3/27 Jesse Keating <jkeating@xxxxxxxxxx>: > > > > > > > > > > > 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
