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