Serge Hallyn <serge.hal...@ubuntu.com> writes:
> 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.)
I have not thought about a less than superprivilege revoke.
Is this vhangup happening on pseudo-tty acting as /dev/console?
Part of me really wants to say the answer should be don't do that then.
Reading the code the current unprivileged uses of tty_vhangup are:
- The pty master closing.
- A session group leader exiting with a controlling tty (that is not a pty).
Which suggests that if you are root in the user namespace of the session
that currently owns the tty it is reasonable to force a hangup for
regulary ttys. I don't know about ptys.
I guess that would require capabilities in ns_of_pid(tty->session)->user_ns.
Being able to kill the process that is the pty master also seems
reasonable.
However I don't think either of those really answer the question for
when it is ok send vhangup to a pty whose master lies outside of the
current user namespace. Which I am pretty certain is the case in
question.
Eric
------------------------------------------------------------------------------
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
