Skip to content
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

Find fusermount on the $PATH #31

Closed
probonopd opened this issue May 9, 2024 · 3 comments
Closed

Find fusermount on the $PATH #31

probonopd opened this issue May 9, 2024 · 3 comments

Comments

@probonopd
Copy link
Member

probonopd commented May 9, 2024

We cannot rely on the compile-time FUSERMOUNT_DIR at build time but have to look at the $PATH on the target system at runtime, because distributions agree on nothing.

Use case:

Essentially we need to reinstate findBinaryOnPath from f0e35b0.

@probonopd probonopd changed the title Find fusermount on the $PATH in addition to relying on compile-time FUSERMOUNT_DIR Find fusermount on the $PATH May 9, 2024
probonopd added a commit that referenced this issue May 9, 2024
@TheAssassin
Copy link
Member

Can't we send the required syscall(s) directly without requiring an external utility to be present on the system?

@probonopd
Copy link
Member Author

That'd be awesome. But the way I understand it that'd mean that we'd have to be setuid root, which is obviously not an option. (They always say FUSE is "in userland", but it still requires code that runs as root - that is fusermount.)

@probonopd
Copy link
Member Author

Test case:
On NixOS, AppImages fail to find FUSE.

With FUSERMOUNT_PROG=$(which fusermount) ./My.AppImage it works nicely. So this is something we definitely need to fix in the AppImage type2-runtime. Apparently it doesn't search for fusermount on the PATH properly yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants