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

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

[Christian Brauner]

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.

If possible, please Cc me on this since I'm not subscribed to the mailing list
(yet).

Thanks!
Christian

Christian Brauner (1):
  openpty: use TIOCGPTPEER to open slave side fd

 src/misc/openpty.c | 34 +++++++++++++++++++++++++++++++---
 1 file changed, 31 insertions(+), 3 deletions(-)

-- 
2.14.1

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

[Christian Brauner]

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/

Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
---
 src/misc/openpty.c | 34 +++++++++++++++++++++++++++++++---
 1 file changed, 31 insertions(+), 3 deletions(-)

diff --git a/src/misc/openpty.c b/src/misc/openpty.c
index c1074060..9eab7a37 100644
--- a/src/misc/openpty.c
+++ b/src/misc/openpty.c
@@ -3,13 +3,14 @@
 #include <unistd.h>
 #include <pty.h>
 #include <stdio.h>
+#include <string.h>
 #include <pthread.h>
 
 /* Nonstandard, but vastly superior to the standard functions */
 
 int openpty(int *pm, int *ps, char *name, const struct termios *tio, const struct winsize *ws)
 {
-	int m, s, n=0, cs;
+	int m, s = -1, cs;
 	char buf[20];
 
 	m = open("/dev/ptmx", O_RDWR|O_NOCTTY);
@@ -17,13 +18,38 @@ int openpty(int *pm, int *ps, char *name, const struct termios *tio, const struc
 
 	pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &cs);
 
+	if (!name) name = buf;
+
+#ifdef TIOCGPTPEER
+	int ret;
+
+	/* Try to allocate slave fd solely based on the master fd in case the
+	 * kernel supports it.
+	 */
+	s = ioctl(m, TIOCGPTPEER, O_RDWR|O_NOCTTY);
+	if (s < 0)
+		goto fail;
+
+	/* Check the contents of the symlink in case devpts has been mounted in
+	 * a non-standard location.
+	 */
+	ret = ttyname_r(s, name, sizeof buf);
+	if (ret)
+		goto fail;
+
+	if (strncmp(name, "/dev/pts/", 9))
+		goto fail;
+#else
+	int n = 0;
+
 	if (ioctl(m, TIOCSPTLCK, &n) || ioctl (m, TIOCGPTN, &n))
 		goto fail;
 
-	if (!name) name = buf;
 	snprintf(name, sizeof buf, "/dev/pts/%d", n);
-	if ((s = open(name, O_RDWR|O_NOCTTY)) < 0)
+	s = open(name, O_RDWR|O_NOCTTY);
+	if (s < 0)
 		goto fail;
+#endif
 
 	if (tio) tcsetattr(s, TCSANOW, tio);
 	if (ws) ioctl(s, TIOCSWINSZ, ws);
@@ -35,6 +61,8 @@ int openpty(int *pm, int *ps, char *name, const struct termios *tio, const struc
 	return 0;
 fail:
 	close(m);
+	if (s >= 0)
+		close(s);
 	pthread_setcancelstate(cs, 0);
 	return -1;
 }
-- 
2.14.1

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

[Rich Felker]

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

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

[Rich Felker]

On Fri, Sep 01, 2017 at 12:00:49PM -0400, Rich Felker wrote:
> 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/
> > 
> [....]
> 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

Actually I'm also rather concerned about security of this whole kernel
patch in general.

Consider the case where a daemon running as root performs
posix_openpt, chowns the corresponding ptsname to a user and hands the
pts off to a user process, then drops from root to nobody, possibly
after chrooting itself or similar. In this scenario it should not be
able to open the user's pts, but with TIOCGPTPEER it can bypass the
filesystem permissions and open it.

I'm not sure what mischief this lets you achieve, but it seems like a
violation of an important permissions invariant...

Rich