Please read the common steps first.
Singularity provides three modes for running containers as a non-root user:
- Setuid mode
- User namespace mode (
singularity exec --userns)
- Fakeroot mode (
singularity exec --fakeroot)
The first one does not fall into the scope of Rootless Containers. In that mode,
the runtime binary gains root privileges via the setuid bit and maps the root user
inside the container to the root user outside the container. Although the setuid portion
of the runtime is kept fairly small, it mounts the contents of a container file as root
and has options to run overlayfs as root (for example
singularity exec --writable).
The second mode does not use setuid root, so it is in the scope of Rootless Containers. In fact, it does not even use a setuid root helper. As a result, it has only one user id directly mapped to the same user id outside the container, and all other user ids including root are mapped to a nobody user id. This limits the types of applications it can run and does not meet OCI container requirements because it cannot run many system-level applications.
The third mode also falls into our scope in that it can avoid its own setuid root runtime
and use only
newgidmap. It should be noted however that it does not
support creating network namespaces with Internet connectivity.
This means that you can’t protect abstract sockets on the host (such as D-Bus sockets)
from being connected from containerized processes, unless you disable Internet connectivity.
This limitation also applies to the second mode.