[Discuss] Debian 12 vs. WSL 1

[Rich Pieri]

On Fri, 16 Jun 2023 19:07:19 -0500
Derek Martin <invalid at pizzashack.org> wrote:

> No. A symlink solves that problem if it's a concern in your
> environment--it never has been in any of mine, even with a mix of
> SunOS, Solaris, HP-UX, and Linux machines.  And this is not actually

Adding custom symlinks to areas owned by the operating system is not a
solution. It's a hack, one that can interfere with any number of
necessary processes like installing security updates. Also, you can't
add arbitrary symlinks like this on read-only volumes such as
super-hardened environments (read-only /usr means an attacker can't
compromise the contents) and containers (which are immutable for their
own reasons).

> particularly different after the change, except that Debian is
> providing those symlinks for you by default.  Most vendors provide a

Kind of the opposite, really: most Linux distributions have either
enforced merged usr (like Fedora and SuSE) or defaulted to it (like
Ubuntu) for years. Debian is the outlier here and that's only because
major Debian releases come slowly: the decision for bookworm to require
UsrMerge was made almost 2 years ago.

> means to automate both installs and post-install customizations; and
> where and when they haven't, generally a shell script suffices, so for
> the most part this doesn't need to be a concern. 

Any thing provided by the OS vendors which removes the need for me and
other sysadmins to maintain custom work is a worth-while improvement.

> > Or have scripts fail to run properly because they can't find
> > /usr/bin/df and /usr/bin/du because they're in /bin?  
> 
> Personally?  No, never.  IMO well-written shell scripts that have to
> live in such environments set their PATH to include the correct
> locations to find things, and rely on the path to find the right ones.

Well-written programs (not just scripts) use absolute paths to ensure
that trojan binaries and libraries are not invoked by privileged
processes. My go-to example is me doing exactly this as a demonstration
to the operators of a bulletin board system where I tricked the system
into loading a root shell instead of the text editor.

YMMV of course but that was such a trivial privilege escalation made
possible by tricking PATH.


> Eh.  It's at best still only a partial solution to the problems you
> described, because you still have things like /opt, /usr/local, or
> whatever else local eccentric admins have dreamt up because they
> could (is /usr/ucb still a thing? maybe that too).  You may not have
> control over that, but if you live in such an environment you'd better
> make sure your tools are robust enough to handle it.

/opt and /local are outside the scope of UsrMerge, but they still are
fallout from K&R splitting usr in the first place over 50 years ago.

/usr/ucb is a special case of BSD-style utilities on SYSV-style Unix. I
don't know if any Unix vendors still provide it but it's still a straw
man: there has never been corresponding /ucb needing to be merged.

> > But what are the benefits of split usr?  
> 
> The main benefit NOW is that it has been this way, so people expect
> it to be this way, and by not changing it you avoid the risk of

yada-yada.

I see two flaws with this.

First is that "we've always done it this way so we must continue doing
it this way". 'nuff said there.

Second is that the UsrMerge changes are entirely transparent to users
and usually are transparent to sysadmins as well. My Debian on bare
metal and virtual machines all upgraded without problems. It's only the
odd cases like how WSL1 locks the filesystem that need special
handling. The point of this was to provide a workaround that is easier
to execute than performing fresh installations.

-- 
\m/ (--) \m/