Comment 14 for bug 1263738

Quoting Seth Forshee (<email address hidden>):
> The same basic sequence of events happens with and without user
> namespaces. init sheds its tty with setsid() but then opens
> /dev/console, which as the effect of making /dev/console it's
> controlling tty. Later getty also opens /dev/console and tries the
> TIOCSCTTY ioctl on the fd. At this point I think the following code in
> the kernel handling of that ioctl comes into play:
>
> if (tty->session) {
> /*
> * This tty is already the controlling
> * tty for another session group!
> */
> if (arg == 1 && capable(CAP_SYS_ADMIN)) {
> /*
> * Steal it away
> */
> read_lock(&tasklist_lock);
> session_clear_tty(tty->session);
> read_unlock(&tasklist_lock);
> } else {
> ret = -EPERM;
> goto unlock;
> }
> }
>
> I.e. getty doesn't have CAP_SYS_ADMIN and thus can't steal the console
> from init. I'm not sure what the fix is yet, whether there's something
> we can do here which can allow root within a namespace to steal the
> console or whether upstart just needs to explicitly shed the console
> after opening it.

If it is possible to get to the inode backing the tty at this point
then we should be able to do inode_capable(tty_inode(tty),
CAP_SYS_ADMIN), which should be safe and adquate right?

But I dont' think we can get inode from tty. However we can get the
tty->session which is a struct pid*. So we can check whether we have
ns_capable(ns_of_pid(tty->session), CAP_SYS_ADMIN)

-serge