As I was testing on LXD, I have some questions and want to ask a question.
What does the security.idmap.isolated option mean in the operating environment?
By setting this option and “/ etc / sub {u, g} id”, restarting the lxd daemon, and creating or starting containers and virtual machines, i can see that each container and virtual machine has a different owner.
Please explain the advantages from a security standpoint as each container has a different owner.
What are the advantages of using shiftfs besides saving boot time on container startup?
In the case of shiftfs, i know that the kernel version is supported by 5 or higher. The host is rhel 8.2 and the kernel version is 4.x. Is there a way to use shiftfs in centos?
(Moving up the centos kernel version to the latest 5.6 does not load shiftfs with modprobe shiftfs.)
Please tell me the minimum kernel version to use LXD’s system call interception feature.
When lxc info in centos7 version, it was confirmed that seccomp is not supported, and in kernel version 5.x, it was supported.
You answered that shiftfs can share volume / path between isolated containers.
Does this mean the same concept as volume sharing in Docker containers?
or does it mean that 2 containers can see the same volume at the same time, like gpfs?
I would like to do a test, but please give me an approximate procedure to follow.
If you have any data on how to build shiftfs using the dkms version, please share it.
Can I use npiv (HBA virtualization) in LXD?
I checked that mount interception works well through testing.
What are some useful syscall interceptions?
Please give me some guidelines to test useful interception.
I’m not familiar with this, but I suspect it would require namespacing of device mapper and block devices to be able to dynamically show up in a container, which isn’t a thing the kernel supports at this point. We’re doing some work on block devices in containers through upstream kernel work on loopfs at this point, which may set precedence to allow more block handling, but we’re likely years away from having much more available there.
setxattr/mknod are used primarily to trun Docker containers, main use of mount interception is to allow mounting trusted block devices or setup redirection of mount over to FUSE.
After enabling lxd’s shiftfs function, I checked that the created volume is shared by 2 containers.
However, after disabling the shiftfs function of lxd, I did the same test.
The result is that the created volume is shared by 2 containers, regardless of whether shiftfs is enabled or not.
I created a file in one container for a shared volume, and deleted a file created in another container. It worked normally.
Am I misunderstanding your words, or did I do the wrong test?
Shiftfs is supported from the kernel version as shown below.
When the privileged mode of the two containers is true, the volume sharing of the two containers is successful for the volume regardless of whether the shiftfs function is activated.
If the privileged mode of two containers is false while the shifts function is enabled, an error occurs as shown in the figure above.
Privileged containers do not use uid/gid maps, that’s what makes them privileged, so shiftfs is irrelevant in that case.
Unprivileged containers can be isolated, making them use separate maps and indeed failing as above.
So it’s all correct so far. Now in the unprivileged case, if your two containers were created on a system where shiftfs is enabled lxc info | grep shiftfs, then the sharing would be allowed too.
