Is lack of supplementary groups support a blocker for non-setuid SingularityCE?

[dtrudg]

Unlike many other container runtimes, SingularityCE continues to use a setuid helper binary by default. The setuid helper binary is used to start containers without requiring an unprivileged user namespace to be entered first. Historically, the setuid binary was required because older Linux distributions didn't support unprivileged user namespaces at all, or because user-mode FUSE filesystems weren't developed / performant enough. Therefore, it was impossible to avoid using setuid for practical applications on HPC systems.

In SingularityCE 4.0 we plan for the new --oci runtime mode to be unprivileged, without a setuid helper ¹. This means it will always require and use unprivileged user namespaces. There is at least one significant remaining drawback of unprivileged user namespaces - you will not be a member of supplementary groups that you are in on the host. This is due to unavoidable limitations with user/group mapping.

On HPC systems it is relatively common for project data to be arranged in cross-lab / cross-department groups, where access is provided using supplementary groups. It may be possible to maintain this access for existing files only, using a trick implmented by the crun low-level runtime. However, inside the container it will not be possible to create any new files using the supplementary groups. There is a partial workaround available, as you can choose which of your groups to use as primary via the newgrp command, before starting a container. However, you cannot switch between / chgrp etc. with other groups in the container.

We are interested in knowing whether the supplementary group limitation would prevent you from using non-setuid SingularityCE.

---

¹ No SingularityCE provided set-uid helper. It will require the limited newuidmap/newgidmap ID mapping binaries, which are setuid and provided by Linux distributions.