I have a application from LXC container. It need exec dmidecode. But when i exec the cmd, it give me the following:
./dmidecode
dmidecode 2.8
/dev/mem: Operation not permitted
I had executed the following
$ lxc config device add container-name source=/dev/mem unix-char path=/dev/mem
But the issue is still there. So my question is how to access /dev/mem for host from container. Or how to map the /dev/mem of host to /dev/mem of containter.
I may be wrong, but I suspect that dmidecode is performing an ioctl or something along those lines, which even if you have write access to the char device will still hit a permission check in the kernel and be denied for non-root users (including root inside an unprivileged container).
You may want to try with a privileged container, that’d likely work then.
I have upgraded lxd to 3.8, I had used lxc init to generate the config. So, don’t see any lxc.include lines as you mentioned.
Also, i modify my config from gentoo /var/lib/lxc/app1/config as the following as your suggestion:
#lxc.cap.drop = sys_module #lxc.cap.drop = mac_admin #lxc.cap.drop = mac_override #lxc.cap.drop = sys_time
lxc.cap.keep = sys_rawio —> add this line
I am able to see the added line, but i am not able to see thru cmd:
lxc config show app1
Could you let me know if it is possible to see /dev/sys, /dev/mem, /dev/proc for host from container? Or we are able to map /dev/sys, /dev/mem, /dev/proc for host into container.
This is very important because my customer’s application need generate certificate thru dmidecode.
I will let my customer know if this is not possible from theory.
The reason it doesn’t work with unprivileged containers is that capable(CAP_SYS_RAWIO) checks whether the caller has CAP_SYS_RAWIO in the initial user namespace which by design unprivileged containers have not.