Quoting Seth Forshee (seth.forshee...@canonical.com): > 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 Ubuntu Server Team, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1263738 Title: login console 0 in user namespace container is not configured right To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1263738/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs