Re: DEP 17: Improve support for directory aliasing in dpkg
Hi,
On Tue, Apr 25, 2023 at 09:07:28PM +0200, Helmut Grohne wrote:
> This and /bin/sh is the kind of files I'd consider important. And then
> upon thinking further it became more and more difficult for me to make
> sense of the objection. On a merged system, we can just move that file
> to its canonical location without having any trouble even with an
> unmodified dpkg. So from my pov, the question about important files can
> be disregarded. I hope Simon Richter agrees.
Yes, the relevant code at
https://github.com/guillemj/dpkg/blob/main/src/main/unpack.c#L749
already handles moving a file inside the same package, and that has
existed for some time, that's why I use two packages for the PoC.
I have not looked for more issues beyond that, so there might be others
lurking in the depths of this code.
What I'm mostly concerned about (read: have not verified either way)
with /lib/ld.so and /bin/sh is what happens when dpkg learns of /bin and
/lib as symlinks -- because right now, the symlinks created by usrmerge
are protected by the rule that if dpkg expects a directory and finds a
symlink, that is fine because that is obviously an action taken by the
admin.
But if dpkg sees a package containing these as symlinks, then this is
entered into the dpkg database, and subject to conflict resolution, and
for that, a separate rule exists that directory-symlink conflicts are
resolved in favour of the directory, so the interaction between a newer
base-files packages shipping /lib as a symlink and an older or
third-party package containing /lib as a directory (e.g. a kernel
package from a hosting provider) could overwrite the /lib symlink.
It might be possible to avoid that by never shipping /lib as a symlink
and always creating it externally, but I still think that's kind of
wobbly.
> If we look deeper into the dpkg toolbox, we pause at diversions. What if
> the new package were to add a (--no-rename) diversion for files that are
> at risk of being accidentally deleted in newpkg.preinst and then remove
> that diversion in newpkg.postinst? Any such diversion will cause package
> removal of the oldpkg to skip removal of the diverted file (and instead
> deleted the non-existent path that we diverted to). Thus we retain the
> files we were interested in.
O_O
Yes. Hahahahaha yes.
Brittle, but it could work. What is a bit annoying is that we'd have to
keep this for an entire cycle.
Simon
Reply to: