Re: Bug#1079124: schroot: regression in 1.6.13-4 when local configuration makes /dev/pts a bind mount
Simon McVittie <[email protected]>
| Newsgroups | gmane.linux.debian.ports.powerpc,gmane.linux.debian.ports.sparc |
|---|---|
| Message-ID | <[email protected]> |
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
0001-setup.d-10mount-Don-t-bind-mount-dev-pts-ptmx-onto-d.patch
(text/x-diff, 2.4 KB)
From: Simon McVittie <[email protected]> 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 <[email protected]> --- 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.