[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: