In summary,
there are three robust ways this can be solved.
One would be for the kernel to implement a new (much nicer than the
current) semantics, where once a task does 'mount -t devpts -o
newinstance', all subsequent devpts mounts (until the next newinstance)
mount the new instance. This woudl be ideal.
The second is with user namespaces. The /dev/pts/* will be owned by the
user namespace which created it, so a child user namespace won't have
access rights. This won't fix the wrong devpts being mounted, but will
prevent access to the ptys themselves.
Finally, it can be handled with the LSMs. In apparmor, there will soon
the ability to specify allowed mount activity by profile. So we can,
after setting up the bulk of the container, switch to a profile not
allowing devpts mounts or umounts. (I hope - I don't recall offhand
whether umount is covered). So if a container tries to mount devpts,
through fstab or otherwise, it will be denied.
Lastly, note that what I previously suggested as a workaround ,namely
adding 'newinstance' to the devpts fstab entry, is not entirely correct
as it may prevent getty on /dev/pts/0 from talking to libvirt's end of
the console.
** Changed in: libvirt (Ubuntu Oneiric)
Assignee: Serge Hallyn (serge-hallyn) => (unassigned)
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/900972
Title:
lxc instance console output spewed to stdout
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/900972/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
