Re: [PATCH 0/1] openpty: use TIOCGPTPEER to open slave side fd

[Rich Felker <dalias@libc.org>]

On Fri, Sep 01, 2017 at 05:35:57PM +0200, Christian Brauner wrote:
> Hi,
> 
> Newer kernels expose the ioctl TIOCGPTPEER [1] call to userspace which allows to
> safely allocate a file descriptor for a pty slave based solely on the master
> file descriptor. This allows us to avoid path-based operations and makes this
> function a lot safer in the face of devpts mounts in different mount namespaces.
> 
> [1]: https://patchwork.kernel.org/patch/9760743/
> 
> The way I wrote this patch it doesn't use the snprintf() and open() routine as a
> fallback in case the ioctl() call fails. If this is a compatibility issue for
> non-Linux systems I can rewrite. But the musl documentation gave me the
> impression that this is not really a concern.

It's a compatibility issue for everything but bleeding-edge Linux.
musl supports all the way back to 2.6.0 and possibly farther, but
especially needs to support actual modern versions people run; you
can't just add dependencies on newly-added features.

There's also no reason for the #ifdef TIOCGPTPEER, as musl decides if
TIOCGPTPEER is defined or not (it has to provide the definition).
Instead, you just need to try the ioctl and fall back if it fails.

Is the TIOCGPTPEER thing upstream in the kernel yet? If not it's not a
stable API and possibly subject to change (even reassignment of the
ioctl number which could be dangerous) so this patch can't be merged
until it's official/permanent on the kernel side.

Otherwise this looks like a good change, but I do wonder a bit about
how the cases where it would help are intended to work, since the
POSIX interfaces for opening a pty require using a pathname
(ptsname[_r]). It seems like only programs using the nonstandard
openpty() function could benefit, and while this interface is nicer in
many ways, it's fundamentally broken in that it lacks a way to
atomically set the FD_CLOEXEC flag. The POSIX functions posix_openpt
and ptsname+open both allow O_CLOEXEC which solves this problem.

Rich