Re: Presenting DPKG_ROOT
Johannes Schauer Marin Rodrigues wrote:
> What do you think? Is this the right solution to the problem? A few more bits
> about DPKG_ROOT as well as alternative solution proposals (including rejected
> ones) can be found on this wiki page:
>
> https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap#Proposal:_chrootless_maintscripts
>
> So lets come back to our question of scope: Right now, our DPKG_ROOT patches
> are limited to Essential:yes, build-essential, apt and systemd. We also
> restrict the mechanism to initial installations only and upgrades are not
> supported. We also currently require that the system (and its tools) on the
> outside must be the same as the chroot that is being created with DPKG_ROOT. As
> far as enabling very early architecture bootstrap goes, this solves the
> problem.
>
> So what do you think? Is this okay? Is there a better solution?
So, first of all, I'm thrilled to see work on improving bootstrapping
and cross-bootstrapping. I'm also thrilled to see DPKG_ROOT being
discussed more broadly.
Regarding the specific solution: the DPKG_ROOT approach has concerned me
since it was introduced, because maintainer scripts run as root, so a
bug in one package's DPKG_ROOT support (let alone the absence of
DPKG_ROOT support) would result in modifying the host system rather than
the target chroot.
I would love to see the DPKG_ROOT support augmented with `unshare`, a
mount namespace, a UID namespace, and a chroot, such that:
- The host filesystem is bind-mounted read-only.
- Host devices are not available (only a minimal /dev); this will also
help ensure bootstraps don't depend on any aspect of the host system.
- The maintainer scripts run as container-root, but not as host-root, so
that they can't accidentally change any aspect of the host.
This could still make use of the existing DPKG_ROOT support; this would
be completely transparent to the maintainer scripts and tools ported
thus far.
This would also allow bootstrapping as non-root, on systems that allow
creating UID namespaces as non-root.
As a bonus, testsuites could use an overlayfs instead of a read-only
bind mount, and then check afterwards if *any* changes occurred in the
overlay, which would be a test failure.
Does that seem like a reasonable addition to the DPKG_ROOT support?
- Josh Triplett
Reply to: