Open dtrudg opened 4 months ago
A full fix for this is complex, requiring invasive changes to the runtime.
As an initial workaround, will add the ability for admins to specify existing network namespaces which a user may join, and a flag for a user to request namespace join rather than creation.
An alternative workaround may be to pass /proc/<pid>/ns
paths to the CNI code that eventually passes them to the DHCP daemon... in the situation that it can be guaranteed that the DHCP CNI daemon and the container are in the same PID namespace.
We have the ability to disable PID namespace creation in singularity.conf
, in which case only a user with privilege can run a container in a different PID namespace. This still needs careful thought for security concerns.. i.e. is PID reuse a possible issue here?
For CE 4.2 we're going for the workaround in #3189 - so a netns with CNI DHCP can be setup separately, and then joined.
Version of Singularity
main / 4.1
Describe the bug
If a CNI plugin is run using dhcp IPAM, two portions of the dhcp plugin are in play:
The dhcp client plugin will communicate with the daemon, and pass the path to a bound network namespace associated with the container. The daemon requires access to this network namespace.
When setting up CNI networks we currently:
There are two problems here:
The bind is not actually applied at CNI setup time, leading to an error such as:
The session directory is not accessible to the dhcp daemon on the host, so it cannot access the container's network namespace.
To support the dhcp plugin we must: