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.

Reply via email to