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.
signature.asc
Description: This is a digitally signed message part
