multiple devpts mounts not supported in sysdeps/unix/sysv/linux/ptsname.c:_ptsname_internal()

[Mike Frysinger]

On Tuesday 11 October 2011 15:05:37 Serge E. Hallyn wrote:
> Quoting Mike Frysinger (vapier@gentoo.org):
> > On Tuesday 11 October 2011 13:15:37 Serge E. Hallyn wrote:
> > > I'm not sure of the best way to fix this in a way palatable to glibc.
> > > Follow the /proc/self/fd/N symlink?  Update the manpages to say the
> > > devpts used must be mounted under /dev/pts by the caller?  (Caller
> > > would need privilege, but can fork+unshare+bind-mount).
> > 
> > doesn't the caller already need privs to chroot in the first place ?
> 
> The caller hasn't chrooted (if he had, then glibc would find /dev/pts/0 :).

sorry, i thought you were talking the other way around.  code running inside 
of the chroot was missing the devpts mount on /dev/pts/.

> > it's been this way for years which means i would have expected all
> > relevant code to have accounted for this already (not saying that it
> > wouldn't be nice to have things "just work" when possible) ...
> 
> It rarely shows up in libvirt, but that's purely by accident since
> /dev/pts/0 is usually in use, and if it isn't the driver creates a pty
> on the host first, which will take /dev/pts/0.  So you have to do
> something to keep /dev/pts/0 from being re-used on the host, but it's
> doable (and has been done and reported).

hmm, maybe i need to read more about pty's and devpts, but this doesn't sound 
right.  you should have "devpts" mounted in /dev/pts/ outside of the chroot, 
and inside of the chroot.  and the way Linux implements the "devpts" pseudo 
fs, there's only 1 actual instance, so all mounts will be in sync 
automatically.  thus /dev/pts/# will be the same pty inside of the chroot as 
well as outside.  maybe there's magic behavior going on with containers ?

> So if the answer is just don't do that, then the manpage should be updated,
> right?  The problem is that unless you look at the implementation, you have
> no idea why grantpt shouldn't work on an fd opened in another ptsns.

glibc doesn't maintain linux man pages ;)

> It'd still be neat if we could fix it for real, but the only way I can
> think of is to follow /proc/self/fd/<fd>, and while i've not thought it
> through i have a feeling that's not a good idea.

looking up symlinks instead of simply asking the kernel via an ioctl sounds 
like a step backwards ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20111011/526c630f/attachment.sig>