Re: [systemd-devel] manually lading kernel modules and have created /dev/* in container?
On Mo, 17.05.21 19:08, Marc Weber (marco-owe...@gmx.de) wrote: > > 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] manually lading kernel modules and have created /dev/* in container?
On Mon, May 17, 2021 at 07:08:55PM +0200, Marc Weber wrote: > > 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] manually lading kernel modules and have created /dev/* in container?
> 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] manually lading kernel modules and have created /dev/* in container?
On Mon, May 17, 2021 at 10:20:50AM +0200, Marc Weber wrote: > 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. That is up to your container, if it wants to mount devtmpfs within it or not. > 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
