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

[Chet Ramey]

On 10/9/17 10:37 AM, Christian Brauner wrote:

> 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.

Bash doesn't try to open /dev/console. It will, however, try to open
/dev/tty and, if that fails, call ttyname() to get the pathname of a
terminal device to pass to open(). The idea is that if you're started
without a controlling terminal, the first terminal device you open becomes
your controlling terminal. However, if that fails, job control will
eventually be disabled -- you can't have job control without a controlling
terminal.

Under the circumstances described in the original bug report, bash attempts
to use stderr as its controlling terminal (having already called isatty and
been told that it's a terminal), discovers that it cannot set the process
group on that, and disables job control. If you can't set the process group
on what you think is your controlling terminal, you're not going to be able
to do job control, period.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/