Systemd heads for a big round-number release

So, for instance, this is more unprivileged than anything that requires a new version of systemd to be running as root: an unprivileged user will often be on some system that sets up subuids/subgids for them and has the setuid helpers because that's what the distro does by default, but the system is running some existing stable release of a distro. (Also, all of this only works if unprivileged user namespaces are enabled, which some distros are clamping down on.)

It is possible to get podman to work without the setuid binaries at all, though - assuming you don't have subuids set up, you can just do podman run --uidmap 0:0:1, and it will realize it doesn't need to map things. (If you do have /etc/subuid and /etc/subgid files but newuidmap/newgidmap aren't actually setuid, e.g. because you're in some no-new-privs mode or using strace or whatever, it's currently a little bit annoying but doable. I got this working with suitable fake subuidmap and subgidmap commands.)

But also, this is a sort of different thing from what systemd-nspawn has gained a privileged helper for. There isn't anything that handles UID/GID mapping in this setup, is there? So the limitation, which would apply to both systemd-nspawn and fully unprivileged podman, is that you only get a single UID/GID inside the container. Which is often fine but not always.

The privileged helper for systemd-nspawn is, as I understand it, an IPC interface to get a mounted root filesystem for the container. podman does not need privilege for that - but it does need FUSE accessible to unprivileged users, which is another common but not guaranteed configuration. (Or, I think, it can just copy a bunch of files with the default "vfs" driver.) I'm curious if you considered a FUSE approach of some sort to allow using untrusted images.