[lxc-devel] User namespaces

[Serge Hallyn]

Quoting Dwight Engen (dwight.engen at oracle.com):
> I finally got around to testing out user namespaces. Very nice to to
> have container root not be kuid 0! One thing that I noticed was that
> mingetty in the container was failing because the call to vhangup(2)
> failed (and thus no lxc-console). I could patch the container to start
> mingetty with --nohangup, but that feels like a workaround and
> wouldn't be good when the terminal got reused in the container. Instead
> I patched my kernel with:
> 
> diff --git a/fs/open.c b/fs/open.c
> index 9b33c0c..7c54d1d7 100644
> --- a/fs/open.c
> +++ b/fs/open.c
> @@ -1059,7 +1059,7 @@ EXPORT_SYMBOL(sys_close);
>   */
>  SYSCALL_DEFINE0(vhangup)
>  {
> -	if (capable(CAP_SYS_TTY_CONFIG)) {
> +	if (ns_capable(current_user_ns(), CAP_SYS_TTY_CONFIG)) {

Note there is a nsown_capable(CAP_SYS_TTY_CONFIG) shortcut for this,
but

>  		tty_vhangup_self();
>  		return 0;
>  	}
> 
> This lets mingetty work, but I'm not so sure it safe to allow a
> CAP_SYS_TTY_CONFIG capable process in the namespace hangup whatever
> terminal it might be able to open and get to be its controlling
> terminal. I guess the terminal would have to be open()able or
> TIOCSCTTY'able in the container, but is that enough protection?
> Thoughts?

I don't think nsown_capable() is sufficient here.  Rather, we need
to check against the user namespace owning get_current_tty().  So what
is that, the get_current_tty()->pgrp->upid[level]->user_ns ?
Or can we walk over the get_current_tty()->tty_files and see if any
of those match?

(Eric cc:d as this may be something he's already thought about.)

-serge