unprivileged/rootless composefs

[cgwalters]

One concern that's come up but we haven't formally tracked is that we can't do "native composefs" (as an EROFS) from an unprivileged context.

There are two overall options:

• Add a system service; I sketched this out in https://github.com/cgwalters/composefs-oci-experimental?tab=readme-ov-file#mounting-composefs-as-non-root and I believe it could be safe.
• Use FUSE (Alex mentioned this, and also a relatively recent big change here is FUSE passthrough landed. Although it itself may not yet work in a userns? Need to look.

Of these I believe the system service should be our default stance; I think we can design it so it's quite low risk to the system.

[hsiangkao]

The first one is what @brauner suggested, I do agree on that, even though EROFS has always been trying hard to get rid of any reported stablity and security issues.

TBH, set FS_USERNS_MOUNT is pretty straightforward for EROFS (we could even isolate a core EROFS on-disk part to enable this, and disallow other complex format), but since it's a strong concern to Linux VFS maintainers and there are enough alternative ways availble, so I don't have a strong tendency for now.

[cgwalters]

There's two sub-paths to such a service. What I was initially thinking here is one where we just create and mount the erofs for the user. That's not going to be much code at all.

The second path is where we have something like flatpak's system pull helper - the container image fetching (literally, the c/image code basically) runs in the user context, but passes content objects via fd passing to the service. It's really much like what I was sketching out earlier in #1849

The advantage of this is pretty huge - it's happened to me not infrequently that I want to run the same image rootful and rootless on a desktop system. In combination with containers/bootc#20 - oh and especially if we bring flatpak on board with this composefs-oriented world...a lot of deduplication and integrity to be had.