Investigate the use of cgroups to replace FUSE (and open lots of possibilities)

[TheAssassin]

Given that tools like podman/buildah/... can mount images within cgroups without root permissions and without FUSE, this may serve as a viable alternative to using FUSE at all. Using cgroups just requires a relatively recent kernel, which most stable distributions nowadays have.

Using cgroups would allow us a lot of fancy additions. For instance, most sandboxing techniques rely on cgroups anyway. Another feature I can think of is writable overlays for AppImages (i.e., using something like aufs or overlayfs to mount a writable layer above the AppImage's filesystem, which, however, seems like some edge case feature to convince existing software to work when packaged into an AppImage, too).

Idea from #877 (comment).

[s09bQ5]

I think what you are referring to is the combination of a user namespace and a mount namespace. An unprivileged user is allowed to create a user namespace, where they have all capabilities. If they then create a mount namespace, they are allowed to mount procfs, sysfs, devpts, tmpfs, ramfs, mqueue, and bpf. They can also create bind mounts. I don't think any of this can serve as an alternative to FUSE for running AppImages.

[TheAssassin]

Thanks for the explanation. I was thinking of using some loop mount to mount the contents instead of using FUSE. I think in type 1, that was one of the supported methods, as the kernel supported mounting ISO9660 images directly. Are those permitted in a mount namespace? We could then mount the contents with the corresponding offset read-only in such a user namespace.

[s09bQ5]

No, a user+mount namespace combination will not allow an unprivileged user to mount a block device like /dev/loopX or /dev/nbdX.

[TheAssassin]

Does not have to be a loop mount, this is just an unnecessary indirection. I'm not sure how podman handles the OCI images, but I guess these are available on disk, extracted into some directory, and not mounted from a file like it is done with AppImages...