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. > > 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?
re-mounting the host filesystem read-only is a good idea for the machinery that
in the end will create chroots using DPKG_ROOT (for example rebootstrap). Note,
that as the normal user, you probably will never need to create a chroot with
DPKG_ROOT because even if you want to create a foreign architecture chroot,
qemu support is available for all our release arches. But if you are involved
in early architecture bootstrapping and want to make sure that chroot creation
does not modify your outer system, then you can create your chroot using either
of the following techniques.
DISCLAIMER: two of our patches have not been applied yet so DO NOT run any of
the below commands unless you really know what you are doing.
1. as the normal user using fakeroot
fakeroot mmdebstrap --variant=essential --mode=chrootless unstable
chroot.tar
2. inside mmdebstrap in unshare mode as a customize-hook
mmdebstrap --mode=unshare --skip=setup,update,cleanup --variant=custom \
--setup-hook='mount -o remount,bind,ro /' \
--customize-hook='mmdebstrap --variant=essential --mode=chrootless unstable
"$1"' \
'' chroot.tar
3. using the (undocumented) mmdebstrap --unshare-helper
mmdebstrap --unshare-helper mmdebstrap \
--setup-hook='mount -o remount,bind,ro /' \
--variant=essential --mode=chrootless unstable chroot.tar
4. using lxc unshare tools
lxc-usernsexec -- lxc-unshare -s 'MOUNT|PID|UTSNAME|IPC' -- mmdebstrap \
--setup-hook='mount -o remount,bind,ro /' \
--variant=essential --mode=chrootless unstable chroot.tar
If you set SOURCE_DATE_EPOCH and add a repo with the last two remaining patches
applied to the packages in the Essential:yes set, then the tarballs created by
either of the commands above will be bit-by-bit identical to tarballs created
like this:
mmdebstrap --variant=essential unstable chroot.tar
Re-mounting / as read-only with an unshared mount namespace is unfortunately
nothing we can test in our CI system because those do not support any unshare
operation. But as a test, re-mounting / read-only is also not useful because
there are scripts which will not error-out if they cannot write something and
we would thus never detect these unintended changes. So instead, in our CI, we
let the maintainer systems write whatever they want, but compare the whole
system state before and after, to make sure that no file on the outside was
modified (even in its metadata).
signature.asc
Description: signature
