On Mon, Dec 2, 2024, 11:20 Simon Richter <
sjr@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.
<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 2, 2024, 11:20 Simon Richter <<a href="mailto:
sjr@debian.org">
sjr@debian.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
On 12/2/24 18:39, Jonathan Dowland wrote:<br>
> This is not correct. Whether any of /usr/bin,/usr/sbin,/bin or /sbin<br> > share a partition or not has no relationship to whether a user can <br> > invoke a command, or whether that path is searched for unqualified <br> > command names (determined by $PATH).<br>
FWIW, I do think that even with user namespaces weakening the <br>
distinction between admin and non-admin users, having things you <br>
normally need root privileges for not take part in tab completion is <br>
still useful to people who use text terminals.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">/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.</div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><br></div></div>
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)