-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fuse: failed to exec fusermount: Permission denied #15
Comments
|
Yeah, I think so too. But in the case of 711 permissions, the runtime shouldn't take fusermount as on option for mounting, right? And have to use built-in method |
I don't think that it works without fusermount, because the AppImage is not run as root. |
Why does it need to read the suid root binary now, and not just execute? And why was it fine to not need it before? |
fusermount was always this way. Nothing changed. |
What do you mean? This is a new error. In the previous version of the runtime the execute bit was sufficient. That's the whole point of the raised issue. |
Please give an example on how to reproduce this - before and after. Thanks! |
Yeah, alright.
To compare the releases it's sufficient to run
Thus, you don't actually need to run the app. For beta.5, the command succeeds with Note that, installing suid root binaries with just the execution bit set for group and others is not uncommon. |
Instead of using
Example:
|
Maybe we should use a custom function like this:
If you have some time to experiment with this, a pull request would be welcome. Thanks for bringing this to my attention @avently and @tsjk. |
@avently @tsjk can you please try the runtime from the artifact linked in #16? You can use it with https://github.com/AppImage/appimagetool by using the |
I think @avently needs to update the build, and then I can try it on my Gentoo systems. Thanks, @probonopd! |
Sorry for the late reply. I use here |
@tsjk please let me know if this fixes it. Thanks! |
What's expected output when you try to run AppImage with /bin/fusermount permissions 4711? I deleted fuse3, keep only fuse2. Run chmod 4711 /bin/fusermount, got this:
|
|
@probonopd in this case the app starts (with 4755) |
OK, then I assume it needs those permissions. Is there something in the fusermount documentation that makes you think otherwise? |
I have no idea how it should work. @tsjk says that it's normal for Gentoo to have 4711. Why is it like this? Have no idea too. If appimage can not work without fusermount, and fusermount is inaccessible, maybe it should print something to log like: "Hey, you use weird fusermount permissions ('actual permissions here'), ask your maintainer to change them to 4755, otherwise, I'm unable to work". And if there is no fuse{2,3} installed, the log should tell about it too. Because when I don't have fuse installed, I can't run AppImage too |
SUID root binaries are often installed as 04711. I think not only on Gentoo. |
I get exactly the same error message. Everything is fine on Ubuntu 22.04 (I used this new runtime to overcome the libfuse2 requirement for modern systems), but on Ubuntu 14.04 I get:
I also tried the patched runtime from #15, but the result is the same. Both However, the AppImage runs fine under root on 14.04, if that matters. |
I looked at the Another observation is that on Ubuntu 14.04, |
BTW, Maybe the problem is that |
With c9553b0, it only looks for fusermount{3,} in On Debian based distributions |
I created a pull request #18 that should fix the permission issue. However, I haven't included the fix for the older systems like Ubuntu 14.04 that only have
|
It's the classic problem that different Linux distribtutions seemingly never can agree on anything (e.g., where in the filesystem things are placed). This is the reason I am using FreeBSD nowadays - there is only one distribution. Anyhow,
Are you sure about this? If yes, then we should definitely do the same. @TheAssassin and I were hesitant about doing this due to it being a setuid program. |
Thinking a bit more about it, if an attacker can somehow modify |
Yes, I'm pretty sure: the original execv(FUSERMOUNT_DIR "/" FUSERMOUNT_PROG, (char **) argv);
execvp(FUSERMOUNT_PROG, (char **) argv); The By the way, if we agree to restore As I understand, the idea behind But since the AppImage runtime uses its own libfuse and needs to find differently named |
Yes. Given your information I am all for it but we should also hear from @TheAssassin. |
Hello. We have an issue with the error mentioned in the title: simplex-chat/simplex-chat#3009
By looking deeply in the situation, @tsjk found what difference we have in our Linux distributions.
In my case on Archlinux I have 4755 permission on the file
/bin/fusermount
.He has 4711 permission on the same file in Gentoo.
When he set 4755 permission, the app can now be launched without the issue.
I see that in the code runtime tries to find fusermount binary:
type2-runtime/patches/libfuse/mount.c.diff
Line 62 in c9553b0
Maybe the function
access
doesn't work correctly? Because it looks like it should return false in the case of 4111 permission, right? It's just a guess, you know better.This is how we package the app if it's important: https://github.com/simplex-chat/simplex-chat/blob/master-ghc9/scripts/desktop/make-appimage-linux.sh
For some unknown reason @tsjk can use our previous beta build of our application with the same permissions on fusermount binary (4711). However, we used the same build process and the same appimagetool binary from Github releases on both beta releases.
Anyway, can we fix the issue somehow from our side or from your side?
The text was updated successfully, but these errors were encountered: