> The user has complete read/write/execute to everything in the 'base' container. Anything bind-mounted in assumes the given privileges from the host system.[0]

> The user has complete read/write/execute to everything in the 'base' container. Anything bind-mounted in assumes the given privileges from the host system.[0] The user's context is essentially mapped to root inside the container, but not a 'true' root in the context of the host system. Sure, but it's actually much simpler than this. User namespaces allow you to change the UID mapping of users -- and an unprivileged user can map themselves to "root" (however, on the host, the user is still the same -- this similar in concept to a PID namespace). However, in a user namespace, filesystem access (plus quite a lot of other things) are restricted based on your real UID/GID. A container image (in order to be used by a user namespace) needs to be extracted such that the owner is the user that you want to execute as. If you were using "root-ful" user namespaces then you could just chown an existing image, but for rootless you need to extract it. My OCI image tool umoci[1] has supported this extraction (it's a bit more complicated than you might think) for about 2 years now. The point is that a container image is generally just a directory (maybe it's a complicated mount hierarchy, but at the end of the day there is a directory that you can "chroot" into -- note that we actually use pivot_root but that's a different topic). > The user can create/modify/run a container without needing root privileges to communicate with a daemon or any other tooling. Yes. The idea is that if you are dropped on a box (with a new enough kernel) with just an unprivileged user, and none of the tools you need are installed, you can still run containers. So all aspects of the container runtime must not require privilege -- and runc has supported this mode since 2016 (I implemented it). > If you don't mind me asking, what came up in your conversations with the Sylabs team? The main disagreement is that they misrepresent runc on their project page[2] -- which is hosted on a .gov website no less. After that there were some further disagreements about whether rootless was something that they actually supported (they don't -- and in fact I was fairly sure I saw several vulnerabilities in their setuid helpers, but I didn't bother looking further into it). Their documentation now says that they've supported rootless containers since 2016 but I don't agree with that statement (it's also so restricted)[3]. I got (somewhat unfairly) angry with them over this whole exchange, so I don't really like discussing Singularity that much anymore. In my first talk about rootless containers, someone actually asks about Singularity[4]. [1]: https://github.com/openSUSE/umoci https://github.com/openSUSE/umoci [2]: http://singularity.lbl.gov/archive/docs/v2-2/faq#why-cant-you-just-use-runc-or-any-other-container-system-on-a-shared-system http://singularity.lbl.gov/archive/docs/v2-2/faq#why-cant-yo... [3]: https://www.sylabs.io/guides/3.0/admin-guide/security.html#how-does-singularity-do-it https://www.sylabs.io/guides/3.0/admin-guide/security.html#h... [4]: https://www.youtube.com/watch?v=r6EcUyamu94 https://www.youtube.com/watch?v=r6EcUyamu94