Hi Johannes, On Sun, May 26, 2024 at 03:26:56PM +0200, Johannes Schauer Marin Rodrigues wrote: > Quoting Helmut Grohne (2024-05-24 14:12:38) > > while working with debusine.debian.net, I ran into a rather crazier kind > > of issue with the unshare backend. It seems like debusine.debian.net > > creates a chroot.tar where resolv.conf is a symbolic link: > > > > | lrwxrwxrwx 0/0 0 2024-05-20 17:15 ./etc/resolv.conf -> > > ../run/systemd/resolve/stub-resolv.conf > > > > Notably, /run/systemd/resolve does not exist inside the tar nor does > > sbuild run systemd-resolved nor systemd-tmpfiles for creating this > > location. When building, the unshare backend tries to bind mount > > /etc/resolv.conf: > > > > | --: 13: cannot create /tmp/tmp.sbuild.OQ0pOU6LQg/etc/resolv.conf: > > Directory nonexistent > > https://debusine.debian.net/artifact/427489/hostname_3.23+nmu2_amd64-2024-05-24T10:06:30Z.build > > > > This fails, because mount attempts to dereference the symbolic link and > > finds that an intermediate directory does not exist. As a result, this > > fails and network generally does not work resulting in all sorts of > > badness. > > I'm not sure where you see bind-mounting /etc/resolv.conf being done in the > $network_setup code. If network is enabled, it reads: > > [ -f /etc/resolv.conf ] && cat /etc/resolv.conf > > "$rootdir/etc/resolv.conf" || echo "nameserver 127.0.0.53" > > "$rootdir/etc/resolv.conf";
Mea culpa. I hallucinated that bind mount, but the effect is the same. The shell redirection follows the symbolic link and figures that it cannot create "$rootdir/etc/resolv.conf". The "Directory nonexistent" error message really comes from the dash redirection: https://sources.debian.org/src/dash/0.5.12-8/src/error.c/?hl=225#L225 I think we should unlink /etc/resolv.conf (as it may be a dangling symbolic link) before creating it. Also note that if you were working with a malicious tar archive and /etc/resolv.conf were an absolute symbolic link, you'd be following it in the initial namespace possibly overwriting precious files. I would not classify this as a vulnerability as we expect the chroot tar to be "sane". > in unshare mode, we are always working with an ephemeral chroot. Would there > be > any downside to sbuild just first running "rm -f $rootdir/etc/resolv.conf" and > then re-creating it as a real file in the $network_setup snippet of > _get_exec_argv() in lib/Sbuild/ChrootUnshare.pm? Not at all. Once my bind mount hallucination goes away, that is the obvious solution. Helmut
