Providing access to loop (and other) devices in containers

LXD
1

I am trying to run openshift in a lxc container in centos7
I am hitting issue after issue trying to do this.
… learning all the pitfalls that can happen…

I ended up adding a device config for every device that may be used eventually in the container.
This looks wrong! There must be a more global way to configure this.
security.privileged = true an security.nesting = true is not helping.

Since my host uses snap a number of loop devices are already in use.

I ended up doing this to make loop devices accessible in the container:

lxc profile set nsmount raw.lxc lxc.aa_profile=unconfined
lxc profile device add nsmount fuse unix-char path=/dev/fuse
lxc config device add nsmount loop-control unix-char path=/dev/loop-control

for i in {0..9}; do echo $i;
lxc profile device add nsmount loop$i unix-block path=/dev/loop$i;
done
and
lxc profile add centos7 nsmount

However, this looks like the wrong way to do it.
Shouldn’t there be a more generic way to define this in apparmor?

2

What you did isn’t too wrong but also not ideal. Unfortunately there aren’t any ideal solution for loop devices as they’re not namespaced.

So any container that you pass loop devices to will be able to see whatever the host or other containers do with those devices…

The alternative to what you did is to use raw.lxc to allow the creation of those devices inside the container, this would be something like this:

raw.lxc: |-
  lxc.cgroup.devices.allow = c 10 237
  lxc.cgroup.devices.allow = b 7 *

And then you’ll need some kind of init script in the container to create the /dev/loop* devices as it’s unlikely that udev will do that for you inside a container.

1 Like
3

I’d like to note that the config is now like this:

  raw.lxc: |-
    lxc.cgroup.devices.allow = c 10:237 rw
    lxc.cgroup.devices.allow = b 7:* rw

According to lxc.container.conf(5) manpage.

4

Oops, sorry about that, yeah, I forgot to specify the file mode.

5

I have a follow-up question/clarification on this topic of providing access to devices in containers. I’m a newbie to containers, so please forgive my inexperience with them. Here’s the question.

When a give access to a host’s device to programs running within a container, what happens to the host’s access to that device? Does it remain accessible to programs running on the host that are not in the container?

6

Yeah, it remains available on the host.
How that behaves very much depends on the device.

It’s the same as having multiple applications or users on the host try to access the device, some only allow one application to open the device, some support multiple concurrent access, some let you but then fail weirdly, …

7

Got it! Thanks …