This is very cool.
I'm trying to get a better sense of how this approach differs technically from rootless Docker / usernetes. I understand that it's not there yet, for many reasons, and I see your FAQ about it, but it's clearly working towards the same goal, right?
I think what's going on is that you depend on shiftfs from Ubuntu, and SECCOMP_RET_USER_NOTIF (or something?), unprivileged user namespaces, cgroup namespaces, etc. from the upstream kernel, but the major missing parts in the upstream kernel are procfs and sysfs virtualization and making shifts feel se amless, and so you've written a syscall trapper and a FUSE filesystem that run on the host and emulate the things you need. Is that approximately right?
If so, I'd be really curious whether you see a path to get onto upstream runc at some future point. It seems like you'd need shiftfs to be upstreamed, but if an unprivileged procfs2 + sysfs2 shows up upstream, I think you can use that? And you'd probably fit in at approximately the place something like vpnkit fits in for managing shiftfs?
I have a use case for this sort of thing at work, and we've been exploring rootless Docker and unprivileged containers a bit. I"m trying to get a sense of why to prefer Sysbox EE instead of waiting for (or, ideally, contributing to) upstream support for namespaced procfs/sysfs, for shiftfs, and for properly teaching Kubernetes about user namespaces. I suppose the answer is that your solution works right now, and upstream support might take years?
I guess that puts you in a position much like OpenVZ and even LXC itself, which both had significant out-of-tree code in years past and seemed to be decently successful businesses as stuff slowly got upstreamed.
It seems like the major benefits of Sysbox EE are paid support and not using the same uid_map for each container?