[PATCH] getpt: use /dev/pts/ptmx as default ptmx master

[Eric W. Biederman]

Christian Brauner <christian.brauner@ubuntu.com> writes:

> For a long time now Linux has placed the ptmx character device directly
> under the devpts mount at /dev/pts/ptmx. The /dev/ptmx path today is
> usually either a symlink, an additional character device or a bind-mount.
>
> The idea has always been to slowly fade-out /dev/ptmx and switch to using
> /dev/pts/ptmx exclusively. The kernel currently maintains code to retain
> backwards compatibility for anyone going through /dev/ptmx.

It depends on who you talk to Linus is against the slow fade-out.

> Specifically, if the ptmx device is opened through /dev/ptmx the kernel
> will look for a "pts" directory in the same directory where the /dev/ptmx
> device node resides. This implies that the devpts mount at /dev/pts and the
> /dev/ptmx mount need to have a common ancestor directory. This assumption
> is usually fulfilled when a symlink or separate device node is used.
> However, this assumption will be broken when /dev/ptmx is a bind-mount of
> /dev/pts/ptmx because they are located on different devices. For a detailed
> analysis of this problem please refer to my upstream patch [1].

We just finished merging the patches that causes this to be a problem
for TIOCGTPEER.

> It is time to start switching to using /dev/pts/ptmx and use /dev/ptmx as a
> fallback only. As far as I can tell, we have three cases to reason
> about:

If we had always had /dev/pts/ptmx there definitely would have been
advantages.  What advantages does it have now to switch to opening
/dev/pts/ptmx?  Especially given that the default permissions are 0000,
so opening /dev/pts/ptmx will fail on most ordinary configurations
today.  Only in containers is /dev/pts/ptmx the prefered device to open.

There is a strong argument for using TIOCGTPEER (this fixes possible
races).  There is a strong argument for having each mount of devpts
be a distinct filesystem (this fixes mount options from a chroot b0rking
the main system).

I don't see a similarly strong argument for asking glibc to always open
/dev/pts/ptmx if available.  It would simplify things, but we have
already dealt with the issues.  So I don't see any real world issues
that it fixes.

Eric