Re: [PATCH 0/1] devpts: use dynamic_dname() to generate proc name

Linus Torvalds
2017-08-26T01:00:40Z

On Thu, Aug 24, 2017 at 4:37 PM, Christian Brauner
<christian.brauner@canonical.com> wrote:
>
> In fact, /dev/ptmx being a symlink or bind-mount is the *standard* in containers
> even for non-user namespaced containers or containers that do not retain
> CAP_MKNOD.

Yes.

I think using /dev/pts/ptmx is nice from a kernel standpoint, but I
really think that user space should *never* use it.

The distro or container setup can do whatever it wants to made
/dev/ptmx then point into the pts directory. Either the traditional
device node, the symlink, or the bind mount works fine. But the point
is that glibc definitely should *not* point to /dev/pts/ptmx itself,
because it's simply not the right path. On lots of distributions that
path simply will not work.

And yes, I agree that the user interface to this all is particularly
nasty. With TIOCGPTPEER we have a nice way to get the pts file
descriptor, but the "normal" way to get to it involves opening a path
given by ptsname(), so we en dup in the crazy situation that we can
easily open the file without the path, but then we use the fd to get
the path (that we didn't need) and then people open it with that path,
because the standard sequence to get a pts is

master = getpt() / posix_openpt() / open("/dev/ptmx", O_RDWR | O_NOCTTY);
grantpt(master);
unlockpt(master);
name = ptsname(master);
slave = open(name, O_RDWR);

which is kind of silly. And I'm not talking about the three different
ways to open the master side. I'm talking about all the rest, which is
all just pretty much garbage.

But I guess none of this is really performance-critical.

Linus