[systemd-devel] manually lading kernel modules and have created /dev/* in container?

[Marc Weber]

Man says:

"

The host system cannot be rebooted and kernel modules may not be
loaded from within the container.
"

https://lists.freedesktop.org/archives/systemd-devel/2015-February/027805.html
said:

"
We nowadays explicitly disallow non-auto loading of kernel modules
from containers, for security reasons. If you want to allow kernel
modules, then you can do so by adding the CAP_SYS_MODULE capability
set to the set of caps to retain in nspawn, by using its --capability=
switch.
"

insmod .ko module works, the problem is that /dev/dahdi appears on host, not within the container.

Is there something simple I missed or do I need to switch to vkvm or such to run maybe 8y old opensuse
on current kernel ?

Marc Weber

[Greg KH]

Post by Marc Weber
"
The host system cannot be rebooted and kernel modules may not be
loaded from within the container.
"
https://lists.freedesktop.org/archives/systemd-devel/2015-February/027805.html
"
We nowadays explicitly disallow non-auto loading of kernel modules
from containers, for security reasons. If you want to allow kernel
modules, then you can do so by adding the CAP_SYS_MODULE capability
set to the set of caps to retain in nspawn, by using its --capability=
switch.
"
insmod .ko module works, the problem is that /dev/dahdi appears on host, not within the container.

That is up to your container, if it wants to mount devtmpfs within it or
not.

Post by Marc Weber
Is there something simple I missed or do I need to switch to vkvm or such to run maybe 8y old opensuse
on current kernel ?

What does vkvm or obsolete opensuse releases have to do with any of
this?

greg k-h

[Marc Weber]

 devtmpfs

thanks. So I can modprobe (-r) the modules from both host/container,

eg dahdi_transcode makes /dev/dahdi/transcode appear.

But when mounting from container I can write / read from it (getting errors

about channels not setup which is probably expected), but I when trying same from the container I

just get operation not permitted. chmod 777 or such doesn't help.

I am not using UID/-U id rewriting in any way. I run the container with --capability=all.

Is there something else I am missing ?



Marc Weber

[Greg KH]

Post by Marc Weber

 devtmpfs

thanks. So I can modprobe (-r) the modules from both host/container,
eg dahdi_transcode makes /dev/dahdi/transcode appear.
But when mounting from container I can write / read from it (getting errors
about channels not setup which is probably expected), but I when trying same from the container I
just get operation not permitted. chmod 777 or such doesn't help.
I am not using UID/-U id rewriting in any way. I run the container with --capability=all.
Is there something else I am missing ?

Sounds like you need to ask about this with whatever framework your
"containers" are being created with. It's not a systemd issue here, and
as the kernel is working properly, doesn't seem to be a kernel issue
either.

Your "containers" are probably set to not allow access to these device
nodes, and rightly so, as that's not normally a good thing to allow.

good luck!

greg k-h

[Lennart Poettering]

Post by Marc Weber

 devtmpfs

thanks. So I can modprobe (-r) the modules from both host/container,
eg dahdi_transcode makes /dev/dahdi/transcode appear.
But when mounting from container I can write / read from it (getting errors
about channels not setup which is probably expected), but I when trying same from the container I
just get operation not permitted. chmod 777 or such doesn't help.
I am not using UID/-U id rewriting in any way. I run the container with --capability=all.
Is there something else I am missing ?

nspawn containers have a strict device policy set up by default. You
need to allow-list your device nodes if you want to be able to use
them from inside the container. Use nspawn's --property= parameter to
tweak this, and set the DeviceAllow= property with it, as needed.

Devices aren't reasonably virtualized for containers
though. i.e. sysfs isn't virtualized and udev doesn't even get
started. Thus, by using --property=DeviceAllow= in combination with
--bind= to make specific device nodes of the host available in a
container you'll really just get the naked devicenodes and not
more. This is typically not enough to run any non-trivial software
that wants to to device management, since the enumerate/monitor
devices via sysfs/uevents/udev and that kind of stuff simply doesn't
work in containers.

Lennart

--
Lennart Poettering, Berlin