On Wed, 2017-02-15 at 11:13 +0000, Simon McVittie wrote:
> On Sat, 26 Nov 2016 at 10:27:38 +0000, Ben Hutchings wrote:
[...]
> > The temporary workaround with /dev/ptmx could be made optional. It's
> > not OK to break the previously working configurations.
>
> If I'm understanding the situation correctly then the next best thing would
> seem to be:
>
> - ln -s pts/ptmx $TARGET/dev/ptmx
> + # Inside a container, we might not be allowed to create /dev/ptmx.
> + # If not, do the next best thing (but see #817236).
> + mknod -m 666 $TARGET/dev/ptmx c 5 2 || ln -s pts/ptmx $TARGET/dev/ptmx
>
> which would result in debootstrap inside a container continuing to create
> a /dev that current schroot etc. cannot successfully use (but that's maybe
> better than it failing completely?), whereas debootstrap outside a container
> would create a /dev that works fine?
That seems reasonable.
> Is there a reason why mounting /dev/pts results in 000 permissions
> on /dev/pts/ptmx? That seems odd. If it didn't, then what debootstrap
> does would work.
It *is* odd. I think the assumption was that normally you carry on
using a simple device node at /dev/ptmx but you can opt-in to using
/dev/pts/ptmx through mount options.
> I notice that systemd creates a symlink when making a new namespace, but
> systemd also mounts /dev/pts with newinstance,ptmxmode=0666 when making a
> new namespace, and existing tools like schroot and pbuilder presumably
> don't do that. Should they?
Yes, I think so. ('newinstance' is always enabled in recent kernel
versions, but must be enabled explicitly for older kernel versions.)
> Or would that break the ability for an
> interactive shell inside the chroot to have its stdin/stdout/stderr
> point to the pty created by an xterm, screen or equivalent outside the
> chroot?
I don't think so. I don't see why that would happen.
Ben.
--
Ben Hutchings
Lowery's Law:
If it jams, force it. If it breaks, it needed replacing
anyway.
Attachment:
signature.asc
Description: This is a digitally signed message part