Quoting Dwight Engen (dwight.en...@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
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
