** Changed in: upstart (Ubuntu Trusty)
Importance: Undecided => High
--
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 c
This seems to be fixed the in the trusty version of upstart, although no
debian/changelog entry was created for this bug.
** Changed in: upstart
Status: Fix Committed => Fix Released
** Changed in: upstart (Ubuntu Trusty)
Status: Confirmed => Fix Released
--
You received this bug
** Tags added: bot-stop-nagging
** Changed in: linux (Ubuntu)
Status: Incomplete => New
--
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 name
** Changed in: linux (Ubuntu)
Importance: Undecided => High
** Tags added: kernel-key trusty
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https:/
Do you happen to know if this is also an issue in the latest mainline
kernel[0]?
[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13-rc6-trusty/
** Changed in: linux (Ubuntu)
Status: Confirmed => Incomplete
** Also affects: linux (Ubuntu Trusty)
Importance: High
Status: Inco
One additional question, do you happen to know if this is a regression?
Did this not happen with previous releases/kernels?
** Tags removed: kernel-da-key
** Tags added: kernel-key
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in
I tried the kernel patch from the mailing list, but that doesn't fix the
problem. It does fix permissions for most /proc/pid/* files in setuid
processes, but the console problems remain.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linu
I straced bash, and I think this is what ends up causing job control to
be disabled:
ioctl(255, SNDRV_TIMER_IOCTL_SELECT or TIOCSPGRP, [1144]) = -1 ENOTTY
(Inappropriate ioctl for device)
255 is stderr duped to a high fd, so it looks like whatever stderr is
mapped to is not a tty.
--
You receiv
stderr actually is mapped to a pty. The problem seems to be that getty
can't set /dev/console as its controlling terminal because it's already
the controlling tty for init, which is in a different process group.
Thus getty ends up with no controlling tty, this is inherited by bash,
and thus bash ca
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 thi
Serge: I've got a patch that fixes the problem. I've uploaded a test
build along with the patch to:
http://people.canonical.com/~sforshee/lp1263738/linux-3.13.0-3.18~lp1263738v201401152110/
I still want to verify that it's impossible to steal a tty from a
process in a parent namespace, but if tha
** Also affects: upstart
Importance: Undecided
Status: New
--
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 conf
I've added an upstart task to the bug. After looking a bit more it seems
upstart is trying to always open terminal devices with O_NOCTTY, so the
tty ownership by init is likely unintentional and therefore a bug. I
haven't been able to find where in upstart this is happening, but on the
kernel side
> I haven't been able to find where in upstart this is happening, but on the
> kernel side I can tell that it's due to an open() without
> O_NOCTTY.
Upstart does not open /dev/console without O_NOCTTY afaics. Are you sure
your kernel debug is showing pid 1 is doing this?
--
You received this b
** Tags removed: kernel-key
--
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 Upstart:
New
St
I figured out what's happening. lxc sets up /dev/kmsg as a symlink to
/dev/console, init fopens kmsg, and suddenly it owns the console. Not
sure whether the fix is to handle kmsg differently or special-case it in
upstart to be opened with O_NOCTTY. I'll leave it to Serge and James to
figure that ou
** Branch linked: lp:~jamesodhunt/upstart/kmsg-noctty
--
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
S
@Serge - perfectly happy to change that, in fact...
@Stéphane - could you review and test lp:~jamesodhunt/upstart/kmsg-
noctty? Thanks!
--
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/12637
** Changed in: upstart
Assignee: (unassigned) => James Hunt (jamesodhunt)
** Changed in: upstart
Status: New => Fix Committed
** Also affects: upstart (Ubuntu)
Importance: Undecided
Status: New
** Changed in: upstart (Ubuntu Trusty)
Status: New => Confirmed
--
You
I'm closing the lxc task as there's nothing we can do in lxc itself to
avoid this, the upstart and kernel patches will solve this for us.
Btw, the branch proposed by James above does work fine for me and has
since been accepted upstream, the next upload should include this fix.
** Changed in: lxc
Yup, just tested, same still happens.
ls -l /proc/1/* shows everything belonging to root. But picking
my login process,
root 631 1 0 19:43 ?00:00:00 /bin/login --
I get:
dr-xr-xr-x 2 root ubuntu 0 Jan 2 19:43 attr
-rw-r--r-- 1 nobody nogroup 0 Jan 2 19:43 autogroup
-r---
Quoting Joseph Salisbury (joseph.salisb...@canonical.com):
> One additional question, do you happen to know if this is a regression?
> Did this not happen with previous releases/kernels?
This is not a regression, it has never worked right.
We believe the problem is that if a task is !dumpable, th
Quoting Seth Forshee (seth.forshee...@canonical.com):
> I tried the kernel patch from the mailing list, but that doesn't fix the
> problem. It does fix permissions for most /proc/pid/* files in setuid
> processes, but the console problems remain.
That's interesting! Thanks for testing.
--
You r
Quoting Seth Forshee (seth.forshee...@canonical.com):
> stderr actually is mapped to a pty. The problem seems to be that getty
> can't set /dev/console as its controlling terminal because it's already
> the controlling tty for init, which is in a different process group.
> Thus getty ends up with n
On Tue, Jan 14, 2014 at 08:42:06PM -, Serge Hallyn wrote:
> Note that what you describe should also be the case if using a regular
> container
>
> sudo lxc-create -t ubuntu-cloud -n u1
> sudo lxc-start -n u1
>
> Is the process group of init somehow ending up different in the user
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/consol
On Wed, Jan 15, 2014 at 06:37:41PM -, Serge Hallyn wrote:
> 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
Quoting Seth Forshee (seth.forshee...@canonical.com):
> On Wed, Jan 15, 2014 at 06:37:41PM -, Serge Hallyn wrote:
> > 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 a
On Wed, Jan 15, 2014 at 07:53:54PM -, Seth Forshee wrote:
> On Wed, Jan 15, 2014 at 06:37:41PM -, Serge Hallyn wrote:
> > 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 sa
On Wed, Jan 15, 2014 at 08:18:04PM -, Serge Hallyn wrote:
> The ns_capable line doesn't check the capabilities of tty->session,
> but rather current's capabilities targeted toward the user namespace
> which owns tty->session.
Okay, this was my fundamental misunderstanding. It makes sense now.
On Mon, Jan 20, 2014 at 06:30:24PM -, James Hunt wrote:
> Upstart does not open /dev/console without O_NOCTTY afaics. Are you sure
> your kernel debug is showing pid 1 is doing this?
Yes, pid 1 within the namespace at least. I couldn't find anywhere where
upstart opened /dev/console without O_
Hi James Hunt,
can you comment on how you would feel about opening /dev/kmsg with
O_NOCTTY ?
--
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 namesp
32 matches
Mail list logo