[buildd-tools-devel] Bug#856877: schroot: Please consider mounting a new instance of /dev/pts

[Simon McVittie]

Package: schroot
Version: 1.6.10-3
Severity: normal
Tags: upstream

As documented in
<http://lxr.free-electrons.com/source/Documentation/filesystems/devpts.txt?v=3.16>
and in <https://www.kernel.org/doc/Documentation/filesystems/devpts.txt>
(for historical context you might want to read the v3.16 version, chosen to
represent Debian jessie, before the latest version), the preferred way to
set up /dev/pts inside containers in recent kernels is to mount a new
instance of the devpts filesystem on /dev/pts, either use ptmxmode=666 or
chmod /dev/pts/ptmx to 0666 afterwards, and arrange for /dev/ptmx to be
equivalent to /dev/pts/ptmx via a symbolic link or bind-mount.

In particular, this would make the chroots created by debootstrap
versions 1.0.76 to 1.0.88 (inclusive) work as expected. In those chroots,
/dev/ptmx is a symbolic link to pts/ptmx. That is considered to be a RC
bug in debootstrap (#817236, RC because it broke existing functionality),
and I have proposed a patch; but with my proposed patch, debootstrap
will still create chroots with /dev/ptmx -> pts/ptmx if it is run
in a container manager that restricts device node creation, such as
systemd-nspawn, because that seemed better than failing outright.

Invoking script(1) is a common way to test this.

A nice side-effect of this change, which I discovered while testing a
cut-down version of the same code in a new debootstrap autopkgtest, is
that it makes script(1) work inside "schroot --sbuild" inside a LXC
container on a Debian jessie kernel. Previously, that would have failed.

I'm filing this as a new bug rather than detaching one of the merged bugs
from #817236 because the only one that originally concerned schroot
was #817236 itself, and it would seem needlessly confusing to repurpose
that bug number.

I attach a schroot patch that does as I request. I'm also going to attach
a patch to #817236 that will extend debootstrap's autopkgtest to run a
heavily cut-down version of the same logic, to confirm that it does in
fact work.

Unfortunately, this does cause a regression for interactive use:
processes inside an interactive schroot cannot tell that their
stdin/stdout/stderr is in fact connected to a terminal, because that
terminal is not visible to them. As a result, programs like sudo and
screen will refuse to run, unless wrapped in something like
"script /dev/null". So it might be necessary for schroot to provide
its own pty (one that *is* valid inside the chroot) and forward
input/output to/from the terminal outside the chroot, or something?
(I think that's what container managers like lxc and systemd-nspawn do.)
As a result I'm not tagging this as 'patch'.

Regards,
    S
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Mount-a-new-instance-of-dev-pts-in-the-chroot.patch
Type: text/x-diff
Size: 5286 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20170305/6fea6990/attachment.patch>