Hi, Quoting Josh Triplett (2022-09-11 15:26:52) > 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.
That is correct.
> 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?
Bind-mounting the host system read-only is an interesting idea that we haven't
tried out yet. To avoid unintended modifications of the host system we are
currently testing two different approaches in our CI system:
1. we run the whole chroot creation inside fakeroot. That way, the maintainer
scripts think they are run as root but they actually cannot modify anything
important.
2. we run the chroot creation as root but inside mmdebstrap in unshare mode.
We create a tarball of the outer system before and after running the
DPKG_ROOT method and then compare these two tarballs to make sure that no
changes were done in the outer system.
I think making the outer system read-only via bind-mounts is another valuable
test that we should implement.
Thanks!
cheers, josch
signature.asc
Description: signature
