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

[Christian Brauner <christian dot brauner at canonical dot com>]

On Thu, Mar 15, 2018 at 03:02:14PM -0500, Eric W. Biederman wrote:
> 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.

Thanks for stopping by Eric, if you think it's not worth it I'm not
going to pursue this further.

My main reason for pushing the /dev/pts/ptmx first, /dev/ptmx second was
that all bugs we ever had that caused /proc/<pid>/fd/<nr> symlinks to be
messed were caused by going through /dev/ptmx causing the kernel to go
through "needless" lookup logic in case the devpts filesystem couldn't
immediately be found where the ptmx device was.

Christian