Deny usage of host consoles/ tty to lxc container

lxc

I'm running Ubuntu 12.04.5 LTS (lxc package 0.7.5-3ubuntu69) with a single lxc guest. Everything works fine, except the lxc container seems to use/ mess with the hosts tty devices.

As soon as the container is started I can no longer login into the host using its consoles because after entering the username it always shows me "Unable to determine your tty name." and then just hangs. Syslog on the host slowly fills up with "init: tty1 main process (17911) terminated with status 1" and "init: tty1 main process ended, respawning".

Is there any way to deny lxc access to the hosts consoles/ ttys? Is there any way to fix the host without having to reboot it?

Here's my current lxc container config:

lxc.utsname = guest1
lxc.rootfs = /var/lib/lxc/guest1/rootfs

lxc.devttydir = lxc
lxc.tty = 4
lxc.pts = 1024
lxc.mount  = /var/lib/lxc/guest1/fstab
lxc.arch = amd64
lxc.cap.drop = sys_module mac_admin mac_override
lxc.pivotdir = lxc_putold

# Interface for public network
lxc.network.type=veth
lxc.network.link=br0
lxc.network.flags=up
lxc.network.hwaddr = 00:16:3e:d6:01:04

# Interface for private network
lxc.network.type=veth
lxc.network.link=br1
lxc.network.flags=up
lxc.network.hwaddr = 00:16:3e:d6:01:05

# Deny access to all devices by default
lxc.cgroup.devices.deny = a

# Allow any mknod (but not using the node)
lxc.cgroup.devices.allow = c *:* m
lxc.cgroup.devices.allow = b *:* m

# /dev/null and /dev/zero
lxc.cgroup.devices.allow = c 1:3 rwm
lxc.cgroup.devices.allow = c 1:5 rwm

# /dev/full
lxc.cgroup.devices.allow = c 1:7 rwm

# consoles
#lxc.cgroup.devices.allow = c 5:1 rwm
#lxc.cgroup.devices.allow = c 5:0 rwm
#lxc.cgroup.devices.allow = c 4:0 rwm
#lxc.cgroup.devices.allow = c 4:1 rwm

# /dev/{,u}random
lxc.cgroup.devices.allow = c 1:9 rwm
lxc.cgroup.devices.allow = c 1:8 rwm
lxc.cgroup.devices.allow = c 136:* rwm
lxc.cgroup.devices.allow = c 5:2 rwm

# rtc
lxc.cgroup.devices.allow = c 254:0 rwm

# fuse
#lxc.cgroup.devices.allow = c 10:229 rwm

# tun
#lxc.cgroup.devices.allow = c 10:200 rwm

# hpet
lxc.cgroup.devices.allow = c 10:228 rwm

# kvm
#lxc.cgroup.devices.allow = c 10:232 rwm

Best Answer

It seems the solution to get back the hosts' TTYs was to remove the existing /dev/tty[1-4] devices on the host and recreate them using mknod.

I didn't yet test if lxc breaks them again after restarting the container, but at least the above fixes it.

Related Solutions

LXC container templates

Yes, an LXC container is some config files and a directory within the whole server. If you copy this directory and config files and adjust the parameters you can use it as a template. Just tar it and untar it to the new machine's directory.

Is it possible to start LXC container inside LXC container

I'm going to dispel a few myths here.

This is just a bad idea. I'm sorry. – Jacob Mar 5 at 20:30

I don't see how this is a bad idea. It's really just a chroot inside a chroot. On one hand, it could possibly decrease performance in some negligible manner (nothing compared to running a VM inside a VM). On the other hand, it's likely to be more secure (e.g. more isolated from the root host system and it's constituents).

Do you actually have a real reason to do this? Please remember that questions here should be about actual problems that you face. – Zoredache Mar 5 at 21:52

I agree 100% with the poster's following comment. Furthermore, I think it's safe to assume that everybody who posts a question on here likely thinks that they have a real reason to do [ it ]..

I think, that lxc should be able to simplify VM migration(and backup+recovery too). But I'm not sure about cases, when there is no access to host OS(cheap vps for example). – Mikhail Mar 6 at 11:17

I actually came across this question back in June when I was first diving into LXC for PaaS/IaaS projects, and I was particularly interested in the ability to allow users to emulate cloud environments for development purposes.

LXCeption. We're too deep. – Tom O'Connor Mar 6 at 22:46

I laughed a little bit when I read this one, but that's not, at all, the case :)

Anyway, I eventually set up a VirtualBox environment with a stock install of Ubuntu 12.04 LTS Server Edition after reading all this, thinking that this was 100% possible. After installing LXC, I created a new container, and installed LXC inside the container with apt-get. Most of the installation progressed well, but resulted in error eventually due to a problem with the cgroup-lite package, whose upstart job failed to start after the package had been installed.

After a bit of searching, I came across this fine article at stgraber.org (the goodies are hiding under the "Container Nesting" section):

sudo apt-get install lxc
sudo lxc-create -t ubuntu -n my-host-container -t ubuntu
sudo wget https://www.stgraber.org/download/lxc-with-nesting -O /etc/apparmor.d/lxc/lxc-with-nesting
sudo /etc/init.d/apparmor reload
sudo sed -i "s/#lxc.aa_profile = unconfined/lxc.aa_profile = lxc-container-with-nesting/" /var/lib/lxc/my-host-container/config
sudo lxc-start -n my-host-container
(in my-host-container) sudo apt-get install lxc
(in my-host-container) sudo stop lxc
(in my-host-container) sudo sed -i "s/10.0.3/10.0.4/g" /etc/default/lxc
(in my-host-container) sudo start lxc
(in my-host-container) sudo lxc-create -n my-sub-container -t ubuntu
(in my-host-container) sudo lxc-start -n my-sub-container

Installing that AppArmor policy and restarting the daemon did the trick (don't forget to change the network ranges, though!). In fact, I thought that particular snippet was so important that I mirrored it @ http://pastebin.com/JDFp6cTB just in case the article ever goes offline.

After that, sudo /etc/init.d/cgroup-lite start succeeded and it was smooth sailing.

So, yes, it is possible to start an LXC container inside of another LXC container :)

Best Answer

Related Solutions

LXC container templates

Is it possible to start LXC container inside LXC container

Related Topic