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

[Serge E. Hallyn]

Quoting Mike Frysinger (vapier@gentoo.org):
> On Tuesday 11 October 2011 13:15:37 Serge E. Hallyn wrote:
> > grantpt, ptsname, and ptsname_r make use of _ptsname_internal().  That
> > function works by appending the TIOCGPTN result to "/dev/pts".  The
> > path /dev/pts is hardcoded.  That means that if you call grantpt on an
> > fd from /chroot/dev/pts, and /dev/pts/0 (for instance) does not exist
> > on the host, you'll (wrongly) get back an error.  This has been seen with
> > libvirt (and is easly to verify with a simple testcase).
> 
> `mount --bind /dev/pts /chroot/dev/pts` ?

Sorry, do you mean as a testcase?  You can just
	mkdir e
	mount -t devpts -o newinstance,ptmxmode=0666,mode=0620,gid=5 e
and run granpt on a pty under e/ for which the host doesn't have a
corresponding /dev/pts/N.  I'm attaching a nice simple little test program
by Scott Moser - though it requires that you first make sure /dev/pts/0
doesn't exist on the host.  (For instance, log into desktop, start two
terminals, close the first one, run the program in the second terminal).

> > 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 :).
Now someone needed privs to mount the new devpts, but it's easy to conceive
a separation of duties such that someone is calling ptsname or grantpt
after having dropped the privileges.  At which point the problem IMO is
mainly that there is no indication of *why* there is a failure.

For libvirt, however, it should be able to do work around it if it has
to.

> 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) ...
> -mike

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).

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.

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.

thanks,
-serge
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-virFileOpen.c
Type: text/x-csrc
Size: 2838 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20111011/49097df6/attachment.bin>