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

Re: command_not_found_handle documentation omission

[Dan Douglas]

On 10/08/2017 03:11 PM, Eduardo A. Bustamante López wrote:
> I guess that instead of changing the semantics of
> command_not_found_handle, a new special trap could be added that
> executes in the context of the shell performing the command lookup.

Possible, but magic traps can be ugly. I often end up just calling
a function from one, otherwise there's no locals or positional
params, though you do get to see the params of the calling context as
compensation. A trap would need a new way to pass in the command name
and args.

> Although I'm not sure how valuable it would be (the added complexity).
> Are there any serious uses of the command_not_found_handle aside from
> suggestions during interactive use?

Mostly non-serious uses in bash libraries that implement wacky
features. command_not_found handle is the only "special" function in bash
at the moment. It's reminiscent of discipline functions, which would be
a sensible place to put this. Huge feature to implement though unless
maybe the dynamic variable code can be substantially reused.



signature.asc
Description: OpenPGP digital signature