kernel-packages team mailing list archive

[Serge Hallyn <1263738@xxxxxxxxxxxxxxxxxx>]

Quoting Seth Forshee (seth.forshee+lp@xxxxxxxxxxxxx):
> 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

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1263738

Title:
  login console 0 in user namespace container is not configured right

Status in “linux” package in Ubuntu:
  Confirmed
Status in “lxc” package in Ubuntu:
  Triaged
Status in “linux” source package in Trusty:
  Confirmed
Status in “lxc” source package in Trusty:
  Triaged

Bug description:
  When you create a container in a private user namespace, when you start the
  container without the '-d' flag, that console is not properly set up.  Logging in
  gives you

  -bash: no job control in this shell

  and hitting ctrl-c reboots the container.

  Consoles from 'lxc-console -n $container' behave correctly.

  This may be a kernel issue, as discussed here:

  http://lists.linuxcontainers.org/pipermail/lxc-
  devel/2013-October/005843.html

  so also marking this as affecting the kernel.

  This can be worked around, but really needs to be fixed before trusty
  is frozen.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1263738/+subscriptions