Re: DEP 17: Improve support for directory aliasing in dpkg
Hi Marvin,
On Sat, Apr 29, 2023 at 02:08:37PM -0400, Marvin Renich wrote:
> My understanding from following this thread (and others) is that dpkg
> has a bug that can easily be triggered by a sysadmin replacing a
> directory with a symlink (and some other necessary conditions that don't
> happen very often), which is explicitly allowed by policy. This bug is
I fear that this is more nuanced than it initially looks. While we kinda
support symlinking parts of the directory hierarchy, the implicit
assumption has always been that this never introduces aliasing. In other
words, the target of such a symlink needs to be a location that is not
used by any package.
The problem here arises from introducing aliasing symlinks - which has
never been supported. In that sense, we do not have consensus on whether
this is a bug in dpkg or merely a missing feature.
> the one that is causing the problem with the approach that was chosen by
> the people implementing usrmerge, even though they were aware of this
> problem and a different approach that would have taken two release
> cycles and would not have triggered this bug was considered and
> rejected.
In all fairness, my understanding is that the different approach would
have had different semantics. Not all binaries would have been available
via both / and /usr and that would have resulted in continuous
incompatibility with other Linux distributions.
> If this is correct, then Luca's approach may fix the problem for
> usrmerge, but does not fix the general dpkg bug. (And, IIUC, is going
> to take two _more_ release cycles to fix the problems with usrmerge as
> implemented! Hmm...)
That general dpkg bug is only observable when aliasing happens. Once no
package ships anything inside non-canonical paths, no relevant aliasing
is happening anymore, so we will not experience any symptoms of that
bug. As such, we could call it unsupported again once Luca's approach
has completed. So yeah, I think the beauty of that approach would be
getting out of this mess without patching dpkg. I've not yet fully
convinced myself that this is indeed viable (though I'm trying to).
> The --add-alias solution that has been suggested in this thread seems
> like it would fix the general problem iff policy was changed to require
> sysadmins to use it if they replaced a directory with a symlink.
I don't think we want to support aliasing as a general mechanism
available to administrators.
> I do not understand why the dpkg maintainer has rejected this solution;
> it would still be a fix for the general bug after the usrmerge
> transition has completed. And it would be at least one order of
> magnitude more performant than scanning the filesystem for directory
> symlinks.
The --add-alias mechanism certainly adds significant complexity to the
dpkg code base. Once introduced, it would become API and cannot be
removed anymore, so it introduces a continuous maintenance cost. And if
you disagree with the bug being a bug (and think of it as rejecting to
implement a new feature), that rejection vaguely makes sense. We may
disagree with that reasoning, but it is far from baseless.
So the problem kinda is that aliasing is happening and causes dpkg's
undefined behaviour wrt aliasing to cause problems. We basically have
two ways to fix this:
A. Ensure that no aliasing is happening anymore. (e.g. by
canonicalizing all paths)
B. Make dpkg cope with such aliasing.
And while some seem to see these solutions as complementary, I think we
should build consensus around either option as combining them gets us
the downsides of both without adding benefit.
Helmut
Reply to: