[SOLVED] Question on nested option lxc container

[Elleni]

When nested is enabled in a ct thus proc and sys mounted rw what does that mean for the host? I tested gentoo Container and this only compiles packages if nested feature is enabled. After deleting the vm is proc & sys of the host the same as if the ct with nested enabled never would have been started? Is it correct that latest after a reboot of the host proc & sys are again reset as they are virtual file systems? Thanks for any clarification.

 

[oguz]

hi,

the host's /proc and /sys are mounted with read and write privileges inside the container when the nesting option is enabled. so for the host this means the files in /proc and /sys can be written to by a process in that container with the nesting option enabled.

Is it correct that latest after a reboot of the host proc & sys are again reset as they are virtual file systems?

yes

After deleting the vm is proc & sys of the host the same as if the ct with nested enabled never would have been started?

that depends on what happens in the container, since it has write privileges it can overwrite files. but after a host reboot it should reset again.

the main thing to watch out with nesting is that if /proc and /sys can be written to by that container, then it is a security risk since a malicious user can interact with them to break out from the container to the host machine. therefore it's not recommended to enable this option in untrusted environments.

 

[Elleni]

Understood. I was only playing with gentoo lxc container and compiling some packages. I then wanted to be sure that deleting the lxc container and rebooting the host would revert the hostnode to its normal proc / sys content. So thanks for your explanation and confirmation.

 

[adrian_vg]

hi,

the host's /proc and /sys are mounted with read and write privileges inside the container when the nesting option is enabled. so for the host this means the files in /proc and /sys can be written to by a process in that container with the nesting option enabled.



yes


that depends on what happens in the container, since it has write privileges it can overwrite files. but after a host reboot it should reset again.

the main thing to watch out with nesting is that if /proc and /sys can be written to by that container, then it is a security risk since a malicious user can interact with them to break out from the container to the host machine. therefore it's not recommended to enable this option in untrusted environments.

Just recently started looking into containers in Proxmox.

The nesting bit over here; https://pve.proxmox.com/wiki/Linux_Container, is a bit lacking for my part.

"nesting=<boolean> (default = 0)
Allow nesting. Best used with unprivileged containers with additional id mapping. Note that this will expose procfs and sysfs contents of the host to the guest."

Not sure I quite understand your answer.

Nesting is disabled by default, so what is the advantage to enabling it in a trusted environment, eg in a home-LAN?
Why would you want to enable it at all, considering the security risks mentioned?
Also, what "additional id mapping" is meant above?


Update
Experimented a bit more.
I ran a pve-container with docker installed and installed some docker-containers in that.
If I disable nesting on the pve-container, the docker-containers won't start.
Not sure why this is, yet.

 

[oguz]

Nesting is disabled by default, so what is the advantage to enabling it in a trusted environment, eg in a home-LAN?

it does not bring any advantage unless you want to run docker or other container technologies in LXC.
there are also some usecases with different software utilizing chroots (they won't work in containers without nesting in some cases)

Also, what "additional id mapping" is meant above?

see [0]
basically that the user/group id inside the container can be mapped outside the container. this is relevant in the case of a bind mount in the container, where you want to access something that is available on the host (NFS share, mounted disk, etc.)

[0]: https://pve.proxmox.com/wiki/Unprivileged_LXC_containers

 

[adrian_vg]

it does not bring any advantage unless you want to run docker or other container technologies in LXC.
there are also some usecases with different software utilizing chroots (they won't work in containers without nesting in some cases)


see [0]
basically that the user/group id inside the container can be mapped outside the container. this is relevant in the case of a bind mount in the container, where you want to access something that is available on the host (NFS share, mounted disk, etc.)

[0]: https://pve.proxmox.com/wiki/Unprivileged_LXC_containers

Excellent, thank you!