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

[Christian Brauner]

On Tue, Oct 10, 2017 at 5:44 PM, Chet Ramey <chet.ramey@case.edu> wrote:
> 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.

Right, this was what I found confusing at first that in fact there was
a controlling
terminal but bash didn't initialize job control. Now, I think I simply
traced it down to
some programs not being able to setsid() or not having set setsid() before
exec()ing bash in the child after a fork(). This is what is causing
job control to fail.

Thanks Chet!
Christian

>
> --
> ``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/