Repository navigation
Investigate the use of cgroups to replace FUSE (and open lots of possibilities) #1278
Description
Activity
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.
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.
No, a user+mount namespace combination will not allow an unprivileged user to mount a block device like /dev/loopX or /dev/nbdX.
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...
Podman uses fuse-overlayfs for rootless mounts.
I fear that with how things are currently with unprivileged namespaces, AppImage cannot make use of these technologies. Virtually all popular distributions use systems like AppArmor or SELinux to lock them down, Debian and its derivatives also ship some special kernel patches for this purpose. We cannot really allowlist all AppImages separately...
@TheAssassin if podman, as your first post implies, can mount containers without root permissions and without FUSE, how are they doing it then? @Conan-Kudo implies that FUSE is actually used. The main (only?) downside to using FUSE imho is that there is a suid helper binary needed (outside of the AppImage),
fusermount. Luckily, most systems nowadays ship it by default. So the only real worrisome aspect is that a future version of fusermount might no longer be compatible with the AppImages we build today.I fear that with how things are currently with unprivileged namespaces, AppImage cannot make use of these technologies
Do you think we should still keep this issue open then?
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).