Re: Bug#1079124: schroot: regression in 1.6.13-4 when local configuration makes /dev/pts a bind mount

[Simon McVittie]

On Tue, 20 Aug 2024 at 12:33:22 +0100, Simon McVittie wrote:
> Please see attached. As with the other known regression from 1.6.13-4
> (#1078539), the proposed solution is a change to a conffile, so buildd
> operators could try this manually if desired.

The patch I previously attached here is also available as part of
,
which fixes both this bug and #1078539.

smcv

Re: Bug#1079124: schroot: regression in 1.6.13-4 when local configuration makes /dev/pts a bind mount

[Simon McVittie]

Control: tags -1 + patch

On Tue, 20 Aug 2024 at 12:10:33 +0100, Simon McVittie wrote:
> I'm testing a patch now.

Please see attached. As with the other known regression from 1.6.13-4
(#1078539), the proposed solution is a change to a conffile, so buildd
operators could try this manually if desired.

Tested successfully on a Debian unstable amd64 VM booted into either a
semi-recent unstable kernel (6.9.12-1, the same as the affected -ports
buildds) or the Debian 10 kernel (4.19.249-2 as used on some mips64el
buildds, see also #1050872).

With the unstable kernel, I can rebuild mksh successfully without changes.

With the Debian 10 kernel, I had to edit mksh's debian/control to remove
the klibc build-dependency (use of which requires a Debian 11+ kernel)
but otherwise the build also succeeds.

If I'm reading the kernel's git history correctly, applying the attached
patch would cause schroot to regress on v4.6 or older kernels, which
I hope are not at all relevant to Debian: Debian 9 'stretch' had v4.9,
so even if Thorsten was correct to say that some mips-family buildds are
still on v4.9, this shouldn't break them either (but I hope that he was
misinformed about that, because v4.19 kernels are already a cause for
concern, and we defintely shouldn't be relying on v4.9 in 2024).

> To reproduce:
...
> * edit /etc/schroot/buildd/fstab

Correction, if you are using sbuild in its default configuration on a
developer system, the reproducer is to edit /etc/schroot/sbuild/fstab
instead. To be sure, apply the change to each /etc/schroot/*/fstab.

smcv
From: Simon McVittie 
Date: Tue, 20 Aug 2024 11:37:25 +0100
Subject: setup.d/10mount: Don't bind-mount /dev/pts/ptmx onto
 /dev/ptmx

If /dev/pts is a new instance of devpts with ptmxmode=666, as it is since
commit 271acf6e "Subject: Mount a new instance of /dev/pts in the chroot",
then it's safe to bind-mount /dev/pts/ptmx onto /dev/ptmx because
we explicitly make its mode 0666.

However, if an old conffile has been kept or overwritten by configuration
management (as on debian-ports buildds), or if a profile has been
explicitly configured to bind-mount the host's /dev/pts in preference
to using a new instance, then it is not safe to bind-mount the host's
/dev/pts/ptmx onto /dev/ptmx, because the host's /dev/pts/ptmx will
often have permissions 000 for reasons that are not clear to me.

With recent-ish kernels (v4.7+, with commit eedf265a
"devpts: Make each mount of devpts an independent filesystem" included),
this bind-mount becomes unnecessary, because the kernel automatically
redirects actions on /dev/ptmx to work with an adjacent devpts mount.
It was included in my 2017 patch to accommodate older kernels like
the one in Debian 8 'jessie', but is unnecessary if we can assume a
Debian 9 'stretch' or later kernel.

Bug-Debian: https://bugs.debian.org/1079124
Fixes: 271acf6e "Subject: Mount a new instance of /dev/pts in the chroot"
Signed-off-by: Simon McVittie 
---
 etc/setup.d/10mount | 10 --
 1 file changed, 10 deletions(-)

diff --git a/etc/setup.d/10mount b/etc/setup.d/10mount
index 010b8b4c..31e817dc 100755
--- a/etc/setup.d/10mount
+++ b/etc/setup.d/10mount
@@ -286,16 +286,6 @@ fi
 
 if [ $STAGE = "setup-start" ] || [ $STAGE = "setup-recover" ]; then
 if [ "$(uname -s)" = "Linux" ]; then
-# Depending on how /dev was set up, /dev/ptmx might either be
-# character device (5,2), or a symbolic link to pts/ptmx.
-# Either way we want it to be equivalent to /dev/pts/ptmx, assuming
-# both exist.
-if [ -e "$CHROOT_PATH/dev/pts/ptmx" ] && \
-[ -e "$CHROOT_PATH/dev/ptmx" ] && \
-! [ "$CHROOT_PATH/dev/pts/ptmx" -ef "$CHROOT_PATH/dev/ptmx" ]; then
-mount --bind "$CHROOT_PATH/dev/pts/ptmx" "$CHROOT_PATH/dev/ptmx"
-fi
-
 # If schroot was invoked from a terminal, we still want to be able to
 # access that terminal. lxc and systemd-nspawn achieve this by
 # binding it onto /dev/console; so can we.