Bug#841935: pbuilder: incorrect permissions on /dev/ptmx breaks openpty()

[James Clarke]

On 5 Mar 2017, at 19:53, Simon McVittie <smcv at debian.org> wrote:
> 
> Control: unmerge -1
> Control: severity -1 normal
> Control: reassign -1 pbuilder
> 
> I'm decoupling this bug from debootstrap and making it non-RC because I
> suspect the best long-term solution might be to solve it in pbuilder
> *and* debootstrap, and debootstrap already has a RC bug representing
> the need for a short-term fix.
> 
> On Sun, 06 Nov 2016 at 20:41:38 +0000, James Clarke wrote:
>> newinstance seems to be a world of pain, as then it can’t access the TTY
>> for std{in,out,err}. I tried many months ago and couldn’t get it to work,
>> but would love to be proved wrong.
> 
> I agree with later commenters on this bug that it would be best for
> debootstrap to create /dev/ptmx as a real device node and not a symlink,
> and I have proposed a patch to do that. However, I don't think you can
> avoid newinstance on recent kernels *anyway*: see
> <https://www.kernel.org/doc/Documentation/filesystems/devpts.txt>
> and compare with
> <http://lxr.free-electrons.com/source/Documentation/filesystems/devpts.txt?v=3.16>.
> 
> So if you have trouble with interactive use under particular use cases,
> you're going to have that same trouble with stretch kernels anyway -
> unless you bind-mount the host's /dev/pts instead of mounting your own,
> like schroot does, which comes with its own problems (in my testing it
> didn't work inside an lxc container with the jessie kernel unless also
> bind-mounting the host's (i.e. lxc's) /dev).
> 
> Also, as Marco noted on #817236, if invoking debootstrap in a container that
> restricts device node creation (notably systemd-nspawn), /dev/ptmx
> cannot be created as a real device node, and the only options are to
> make it a symlink or to fail altogether. So it would seem like a good
> long-term plan to make pbuilder tolerate that arrangement? Unfortunately,
> this might involve setting up a pty between the user and the contained
> processes, or using "script /dev/null".
> 
> I attach a possible patch that makes kernels >= 2.6.29 consistent with 4.7+.
> By this point I've mostly lost track of whether it is a good idea or not :-(

So there's nothing inherently wrong with having /dev/ptmx symlink to
/dev/pts/ptmx. The trouble is that /dev/ptmx as a device node is typically 666,
whilst /dev/pts/ptmx defaults to 000, but if you mount it with ptmxmode=666
then everything works. However, this has to be done on the host, since /dev/pts
is currently (effectively) bind-mounted (by not being a new instance), and if
you want to have use newinstance instead to separate the two, the problem is
that the chroot can't access the controlling TTY any more, since it's only in
the host's /dev/pts. I would love to see newinstance working, but I tried it
once and couldn't get it to work, especially with "pbuilder login". Someone
more knowledgeable than me might be able to fix that, and I would welcome their
input.

Regards,
James

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.alioth.debian.org/pipermail/pbuilder-maint/attachments/20170305/eb9b34bb/attachment-0001.sig>