TC decision on ownership of top-level filesystem aliases - #1091995

[Matthew Vernon]

Hello,

In Bug #1091995, the Technical Committe was asked to rule on an issue
that could, under certain circumstances, result in failure of the
base-files package to install or upgrade correctly. Under these
circumstances, systemd will create a symlink from /lib64 to /usr/lib,
which does not match the symlink contained within base-files. base-files
will detect this case in preinst and generate an error, but if it did
not do this then dpkg would instead fail with a less verbose message.

Policy does not currently define ownership of the usrmerge filesystem
aliases, but since trixie base-files has effectively been responsible
for ensuring that these aliases are configured appropriately. This is
therefore a technical disagreement rather than a policy violation.

The Technical Committee affirms that base-files should own all
top-level filesystem aliases, and packages that conflict with this must
be patched in Debian to avoid creating any aliases that conflict with
base-files. In doing so, the Technical Committee overrides the systemd
maintainers.

For complete details of the discussion, please see
https://bugs.debian.org/1091995

Regards,

Matthew (for the Technical Committee)

[Sean Whitton]

Hello ctte,

Post by Matthew Vernon
In Bug #1091995, the Technical Committe was asked to rule on an issue
that could, under certain circumstances, result in failure of the
base-files package to install or upgrade correctly. Under these
circumstances, systemd will create a symlink from /lib64 to /usr/lib,
which does not match the symlink contained within base-files. base-files
will detect this case in preinst and generate an error, but if it did
not do this then dpkg would instead fail with a less verbose message.
Policy does not currently define ownership of the usrmerge filesystem
aliases, but since trixie base-files has effectively been responsible
for ensuring that these aliases are configured appropriately. This is
therefore a technical disagreement rather than a policy violation.

Just to note that the most recent release of Policy sort-of defines
ownership of this, though it is not as explicit as the TC decision:

Packages must not install files to paths whose first component is a
name directly under the file system root and which is a symbolic
link to a directory of the same name under "/usr". ... The
base-files package is an exception, for it installs aliasing
symbolic links from "/bin" to "/usr/bin", "/lib" to "/usr/lib", et
cetera.

[Helmut Grohne]

Hi Sean,

Post by Sean Whitton
Just to note that the most recent release of Policy sort-of defines
Packages must not install files to paths whose first component is a
name directly under the file system root and which is a symbolic
link to a directory of the same name under "/usr". ... The
base-files package is an exception, for it installs aliasing
symbolic links from "/bin" to "/usr/bin", "/lib" to "/usr/lib", et
cetera.

Thanks for highlighting the additional context. A significant angle here
is what it means to "install". systemd does not presently install those
symlinks at package installation time, so it may be argued that it does
in fact not violate the updated policy in this regard.

Even after the requested change has been effected, systemd will continue
to create the aliasing symlinks when missing. This kinda is intended as
a mechanism supporting hermetic-/usr. Longer term, it shall become
possible to install Debian in such a way that the entire installation
lives below /usr (though it will not be possible to upgrade such an
installation due to the lack of /var/lib/dpkg in the initial
implementation). Then systemd may assemble a system from the
Discoverable Partitions Specification
(https://uapi-group.org/specifications/specs/discoverable_partitions_specification/).
It may locate a /usr filesystem and an empty root partition and
initially populate the latter. That population step includes creating
aliasing symlinks such as /bin -> usr/bin. You may argue that this
constitutes an "installation" and thus violates policy.

Can you clarify how you understand policy here?

I read it as systemd is not performing an installation here and
therefore does not violate the present policy. If your reading is
different, we should likely clarify policy on this aspect.

Helmut

[Marvin Renich]

Post by Helmut Grohne
Hi Sean,

Post by Sean Whitton
Just to note that the most recent release of Policy sort-of defines
Packages must not install files to paths whose first component is a
name directly under the file system root and which is a symbolic
link to a directory of the same name under "/usr". ... The
base-files package is an exception, for it installs aliasing
symbolic links from "/bin" to "/usr/bin", "/lib" to "/usr/lib", et
cetera.

Thanks for highlighting the additional context. A significant angle here
is what it means to "install". systemd does not presently install those
symlinks at package installation time, so it may be argued that it does
in fact not violate the updated policy in this regard.

Are you saying that systemd creates the symlinks at runtime when it
finds them missing, rather that when the systemd package is installed?
To me, this is a clear violation of the policy quoted above. "...must
not install..." says nothing about when the installation happens.
Installing a symlink is distinct from installing a package. The act of
creating the symlink is exactly "installing" it, whether it happens at
package installation or later.

...Marvin

Post by Helmut Grohne
Even after the requested change has been effected, systemd will continue
to create the aliasing symlinks when missing. This kinda is intended as
a mechanism supporting hermetic-/usr. Longer term, it shall become
possible to install Debian in such a way that the entire installation
lives below /usr (though it will not be possible to upgrade such an
installation due to the lack of /var/lib/dpkg in the initial
implementation). Then systemd may assemble a system from the
Discoverable Partitions Specification
(https://uapi-group.org/specifications/specs/discoverable_partitions_specification/).
It may locate a /usr filesystem and an empty root partition and
initially populate the latter. That population step includes creating
aliasing symlinks such as /bin -> usr/bin. You may argue that this
constitutes an "installation" and thus violates policy.
Can you clarify how you understand policy here?
I read it as systemd is not performing an installation here and
therefore does not violate the present policy. If your reading is
different, we should likely clarify policy on this aspect.
Helmut

[Helmut Grohne]

Post by Marvin Renich
Are you saying that systemd creates the symlinks at runtime when it
finds them missing, rather that when the systemd package is installed?
To me, this is a clear violation of the policy quoted above. "...must
not install..." says nothing about when the installation happens.
Installing a symlink is distinct from installing a package. The act of
creating the symlink is exactly "installing" it, whether it happens at
package installation or later.

You are reading it correctly. systemd is creating /bin, /lib, /sbin and
in some situations also /lib64 when it finds them missing at runtime
(e.g. during system boot from the initramfs before pivot_root). In a
pretty normal installation this code path is not takes. For one thing,
those links tend to exist and existence prevents systemd from touching
them. For another, our default initramfs does not involve systemd.

If we consider this behavior a violation of the present policy. I
believe that we should change it. Having systemd create those links when
missing is crucial for implementing hermetic-/usr and I see little
reason for our policy to forbid that use case.

What was decided by the CTTE here is that systemd must not create links
that are *incompatible* with the ones base-files creates. In particular,
systemd must not create /lib64 -> usr/lib as a result of the CTTE
decision.

Helmut

[Sean Whitton]

Hello,

Post by Helmut Grohne
Can you clarify how you understand policy here?
I read it as systemd is not performing an installation here and
therefore does not violate the present policy. If your reading is
different, we should likely clarify policy on this aspect.

I read it that way too.

[Matthias Urlichs]

onger term, it shall become possible to install Debian in such a way that the entire installation
lives below /usr (though it will not be possible to upgrade such an
installation due to the lack of /var/lib/dpkg in the initial
implementation).

My "build me a Debian image" script has been doing that for two years
now, simply by moving /var/lib/dpkg to /usr/state/dpkg and bind-mounting
it back onto /var/lib/dpkg (symlinking won't work).

Presto, a /usr subvolume (I'm using btrfs) that's actually consistent
when snapshotted.

Granted that some pieces are missing, most notably /boot (which really
should be populated from /usr (and /etc) instead of being directly
installed to), but that's irrelevant when your usecase is booting
containers, and fixable by reinstalling the kernel packages.

--
-- regards
--
-- Matthias Urlichs

[Marco d'Itri]

My "build me a Debian image" script has been doing that for two years now,
simply by moving /var/lib/dpkg to /usr/state/dpkg and bind-mounting it back
onto /var/lib/dpkg (symlinking won't work).

How so? My /var/lib/dpkg has been a symlink for a very long time.

Granted that some pieces are missing, most notably /boot (which really
should be populated from /usr (and /etc) instead of being directly installed
to), but that's irrelevant when your usecase is booting containers, and
fixable by reinstalling the kernel packages.

See https://www.linux.it/~md/text/factoryreset-asg2024.pdf .

[Matthias Urlichs]

Post by Marco d'Itri

My "build me a Debian image" script has been doing that for two years now,
simply by moving /var/lib/dpkg to /usr/state/dpkg and bind-mounting it back
onto /var/lib/dpkg (symlinking won't work).

How so? My /var/lib/dpkg has been a symlink for a very long time.

Huh. It's been sufficiently long ago that I first did this; IIRC I
simply used a bind mount instead of investigating what replaced the
symlink. If this has since been fixed (by chance?), so much the better.

Post by Marco d'Itri

Granted that some pieces are missing, most notably /boot (which really
should be populated from /usr (and /etc) instead of being directly installed
to), but that's irrelevant when your usecase is booting containers, and
fixable by reinstalling the kernel packages.

Seehttps://www.linux.it/~md/text/factoryreset-asg2024.pdf .

Ah. Thanks.

--
-- regards
--
-- Matthias Urlichs