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