On Thu, Feb 8, 2018 at 5:17 PM, M. J. Everitt <m.j.ever...@iee.org> wrote: > > > On 08/02/18 22:13, William Hubbs wrote: >> On Thu, Feb 08, 2018 at 03:55:02PM -0500, Mike Gilbert wrote: >>> However, there are plenty of examples of commands that normal users >>> may run from sbin. Moving these commands often causes problems for >>> packages that either hard code absolute paths, or detect paths at >>> build time. I think it would be less disruptive to add sbin to PATH >>> than it would be to try and "fix" all the packages that install >>> commands in the wrong place. >> There are no reasons to remove the *sbin directories from PATH; I know >> of no other distros that do this. >> >> William >> > Pardon my ignorance, but does that mean you are essentially relying on > file system features/permissions and security settings to enforce > correct use of system tools?! Or is this just to make sudo/etc commands > 'more convenient' ?!
If you're depending on binaries not being in the PATH for security, you're doing it wrong. If you're depending on filesystem features/permissions (other than the SUID bit or POSIX capability settings) for security when it comes to performing privileged operations, you're also doing it wrong. There are actually quite a few binaries in /sbin and /usr/sbin which can be useful for non-root users. Sure, we could go through there carefully and move stuff to /bin but honestly doing what everybody else does and just sticking /sbin in the default path makes more sense. If you're typing p<tab> to find a command then adding an extra ~20 commands to the ~850 that are listed on my system isn't going to break the bank. -- Rich
