On Mon, Dec 2, 2024, 11:20 Simon Richter <s...@debian.org> wrote: > Hi, > > On 12/2/24 18:39, Jonathan Dowland wrote: > > > This is not correct. Whether any of /usr/bin,/usr/sbin,/bin or /sbin > > share a partition or not has no relationship to whether a user can > > invoke a command, or whether that path is searched for unqualified > > command names (determined by $PATH). > > FWIW, I do think that even with user namespaces weakening the > distinction between admin and non-admin users, having things you > normally need root privileges for not take part in tab completion is > still useful to people who use text terminals. >
This is not and never was the purpose of /sbin and /usr/sbin. It was a bit of mistaken confusion when someone at redhat first thought of removing them from users' PATH and represented a kind of lost memory of the history of this distinction. /sbin and /usr/sbin were always in everyone's path and should be. There are essential programs that are useful to every user in there. It's incredibly annoying when coming across systems that get this wrong. The purpose of /sbin and /usr/sbin was to have statically linked essential programs needed to bring up the network, mount filesystems, and do basic admin work in case your large storage device which might require those tools to mount or repair. This is a necessary feature to achieve a lot of other things like shared /usr volumes and dumb terminals with minimal storage. Everything old is new again and dumb terminals with no local storage are now called cattle servers or netbooks and achieve this in different ways. Saving storage is hardly a priority when cheap laptops have terabytes of storage and being able to manually administer a server when it's off the network isn't how things are done these days. So shared mounted /usr and a minimal /sbin isn't seen as very useful. Personally I don't understand wanting to burn down something useful that could be useful in the future even if it's currently unfashionable. These kinds of things have a way of coming back. But it's absolutely not about user paths or security benefits. (Though shared mounted /usr actually did have some security benefits). It's about breaking the dependency cycles and being able to start up the system workout requiring the entire world to be there already.