Singularity in general requires root, it's just in the form of setuid helpers. Now, you can force it to not require root but from memory there are a lot of caveats with using it that way. Unprivileged LXC is much more full-featured. And obviously rootless runc works great as well (though I'm a bit biased of course).
Singularity is capable of using setuid helpers, but by default it uses user namespaces (the USERNS kernel feature) and does not need the setuid helpers.
Lots of things are 'more full-featured' and none of them work well in an HPC context, where individual user jobs may need to be staged carefully.
> Lots of things are 'more full-featured' and none of them work well in an HPC context, where individual user jobs may need to be staged carefully.
After long discussions with the Singularity folks I've come to the conclusion that the only special features that Singularity has are:
* Their distribution format is a binary containing a loopback block device, allowing you to have "a single thing to distribute" without concern for having to extract archives (because in theory archive extraction can be lossy or buggy). The downside is it requires (real) root to mount or a setuid helper, because mounting loopback is privileged because it opens the door to very worrying root escalation exploits. When running without setuid helpers I'm not sure how they have worked around this problem, but it probably involves extraction of some sort (invalidating the point of having a more complicated loopback device over just a tar archive).
* It has integration with common tools that people use in HPC. I can't quite remember the names of those tools at the moment, but some folks I know wrote some simple wrappers around runc to make it work with those tools -- so it's just a matter of implementing wrappers and not anything more fundamental than that.
Aside from those two things, there's nothing particularly different about Singularity from any other low-level container runtime (aside from the way they market themselves).
A lot of people quote that Singularity lets you use your host user inside the container, but this is just a fairly simple trick where the /etc/passwd of your host is bind-mounted into the container and then everything "looks" like you're still on your host. People think this is a security feature, it isn't (in fact you could potentially argue it's slightly less secure than just running as an unprivileged user without providing a view into the host's configuration). If you really wanted this feature, you could implement it with runc's or LXC's hooks in a few minutes.
