glibc [BZ #22145]: {p,ty}fds and mount namespaces

[Christian Brauner]

Hi,

We've received a bug report against glibc [1] relating to {p,t}ty file
descriptors from devpts mounts in different mount namespaces.  In case
ttyname{_r}() detects that the path for a pty slave file descriptor (e.g.
/dev/pts/4) does not exist in the caller's mount namespace or
the path exists by pure chance (because someone has e.g. opened five {p,t}tys in
the current mount namespace) but does in fact refer to a different device then
ttyname{_r}() will set/return ENODEV. On Linux the caller can treat this as a
hint that the {p,t}y file descriptor's path does not exist in the current mount
namespace. However, in case the path for the {p,t}ty file descriptor
does actually exist in the current mount namespace although the
{p,t}ty fd belongs to a devpts mount in another mount namespace seems
to confuse bash such that bash fails to initialize job control
correctly. This at least is my current analysis of the
problem.
A common scenario where this happens is with /dev/console in containers.
Usually container runtimes/managers will call openpty() on a ptmx device in the
host's mount namespace to safely allocate a {p,t}ty master-slave pair since they
can't trust the container's devpts mount after the container's init binary has
started (potentially malicious fuse mounts and what not).  The slave {p,t}ty fd
will then usually be sent to the container and bind-mounted over the container's
/dev/console which in this scenario is simply a regular file. This is especially
common with unprivileged containers where mknod() syscalls are not possible. In
this scenario ttyname{_r}() will correctly report that /dev/console does in fact
refer to a {p,t}ty device whose path exists in the current mount namespace but
whose origin is a devpts mount in a different mount namespace. Bash however
seems to not like this at all and fails to initialize job control correctly. In
case you have lxc available this is simply reproducible by creating an
unprivileged container and calling lxc-execute -n <container-name> -- bash.  If
you could look into this and whether that makes sense to you it'd be greatly
appreciated.

Fwiw, zsh does not seem to run into a problem here.

Thanks
Christian

[1]: https://sourceware.org/bugzilla/show_bug.cgi?id=22145