Mount a FUSE filesystem without use of root or fusermount (suid)

[probonopd]

As @mgord9518 pointed out:

#32 (comment)

It’s possible to mount a FUSE filesystem without use of root permissions or SUID binaries by doing the mount inside of a user namespace.

VERY interesting @mgord9518. 💯 I think you are up to something. That suid helper binary always bothered be to begin with.

Does anyone know how to actually implement this, in code? Any help appreciated 👍

[mgord9518]

For a trivial example, you can just use unshare --mount --user -r, which will create a fake root environment which FUSE can be mounted from. An issue I see is that it's almost like a sandbox, so the behavior won't just be 1:1 with using fusermount.

Maybe someone should experiment with launching AppImages from this shell environment to see how differently the applications behave before implementing anything in C

[TheAssassin]

user namespace

For security reasons, user namespaces have been restricted resp. locked down more again on many OSes. I could imagine that this would cause issues with rootless FUSE. Plus, they've never been enabled on a lot of popular distros.

[probonopd]

Isn't Bubblewrap using this, too? Which would mean that at least all distributions that support Flatpak should have this enabled by default?

[mgord9518]

Isn't Bubblewrap using this, too? Which would mean that at least all distributions that support Flatpak should have this enabled by default?

As far as I know. I believe it also has an SUID version but normal bubblewrap uses unprivileged namespaces. Even with the distros that disable them (like Ubuntu), many distros still support them out of the box. Nix, Arch and LM right off the top of my head, so assuming we can actually get it to feel like there's no difference it's probably worth it

I've started on making a new AppImage runtime in Zig and I'll try to implement mounting with namespaces

[Samueru-sama]

For a trivial example, you can just use unshare --mount --user -r, which will create a fake root environment which FUSE can be mounted from. An issue I see is that it's almost like a sandbox, so the behavior won't just be 1:1 with using fusermount.

Maybe someone should experiment with launching AppImages from this shell environment to see how differently the applications behave before implementing anything in C

I tested this with the nvtop appimage, it has an odd issue that I can no longer see the active processes, it also breaks the cpu-x daemon.

[dleggo]

Any news on this?

[Samueru-sama]

Any news on this?

I don't think this will be implemented, the ideal solution for now is to set APPIMAGE_EXTRACT_AND_RUN when fuse isn't available.

see this for example

Would be great if the runtime actually did it without having to set the env variable though.

[TheAssassin]

Would be great if the runtime actually did it without having to set the env variable though.

The reason it doesn't is that it's a very inefficient method and we would rather have people set up FUSE. There is a significant share of people running into this who can actually fix FUSE. The few who don't most likely know about the flag.

What I am open to is to check if FUSE does work, then check whether we're in a Docker environment (or other environments which cannot really be fixed) and then print a warning and extract the files. I was objected to that in the past, but given the fact that enabling FUSE in namespaces is a bad idea security wise, it'd be a small quality-of-life improvement to do auto extract.

For the record, the extracting could be optimized a lot to, e.g., cache more reliably.

[Samueru-sama]

Yeah I'm fine with it only being done automatically when we are on some container that doesn't allow SUID binaries.

The uruntime actually cleans up the extracted files when the application stops being used when APPIMAGE_EXTRACT_AND_RUN is used while the type2-runtime leaves them on /tmp.

[TheAssassin]

The uruntime actually cleans up the extracted files when the application stops being used when APPIMAGE_EXTRACT_AND_RUN is used while the type2-runtime leaves them on /tmp.

I think I initially implemented a $NO_CLEANUP and had it always clean up, but I think that was changed at some point to clean up only when asked to because you might end up running two instances at the same time (they both extract/cache in the same path) and then one instance might end up deleting the other's files. There are ways around this, e.g., spinning forking off a small daemon that tracks the instances.

[dleggo]

For cases where FUSE isn't wanted it would be nice to have a user-namespaces option. Personally, to run AppImages, I extract them even though I have FUSE installed just because it is much faster, (1.5x - 2x) but user namespaces can utilize the kernel mounts which are much faster. Additionally, for some users, FUSE is a big barier to entry, and it would be nice to eliminate that for people who have user namespaces enabled in their kernel.

[Samueru-sama]

Personally, to run AppImages, I extract them even though I have FUSE installed just because it is much faster, (1.5x - 2x)

In what AppImages do you see this? With the type2-runtime and zstd compression the overhead I see is usually less than 1 second for most applications. And when it is more than 1 second it is usually apps that have high launch times anyway without being appimage.

There is room for improvement, I personally use the uruntime because it supports dwarfs, which reduces the launch time even more and even with squashfs the uruntime is still slightly faster.

[dleggo]

In what AppImages do you see this?

Time in seconds for applications to launch. (Not perfectly accurate, but I tried to get it as accurate as possible.)
Brave AppImage launch: 3.210
Brave Extracted: 1.960
OnlyOffice AppImage: 3.213
OnlyOffice Extracted: 1.943
VSCode AppImage: 6.754
VSCode Extracted: 6.004
Inkscape AppImage: 3.094
Inkscape Extracted: 1.994

And when it is more than 1 second it is usually apps that have high launch times anyway without being appimage.

This kinda sounds multiplicative to me. :)

I would love to see more work in the area of user namespaces as they have the opportunity to speed up many things that are currently using FUSE! Performance is actually a relatively common complaint against AppImage IIRC, and this would help migate that.

[TheAssassin]

Have you used the flag or pre-extracted the AppImages?