[minor] The way AllowOther is handled is confusing
As a preface, I don't know much about how fuse works.
I created a new rust project, referenced this crate and copied the simple example into main.rs. So far so good.
On startup, it fails with
fusermount3: option allow_other only allowed if 'user_allow_other' is set in /etc/fuse.conf
Of course, the simple option would be to do that, but instead I'm looking for why 'allow_other ' is set at all, because it's not done by me.
Running it with verbose logging shows:
[2024-11-25T23:20:03.185848941Z WARN fuser::session] Given auto_unmount without allow_root or allow_other; adding allow_other, with userspace permission handling
And in session I find:
// If AutoUnmount is requested, but not AllowRoot or AllowOther we enforce the ACL
// ourself and implicitly set AllowOther because fusermount needs allow_root or allow_other
// to handle the auto_unmount option
let (file, mount) = if options.contains(&MountOption::AutoUnmount)
&& !(options.contains(&MountOption::AllowRoot)
|| options.contains(&MountOption::AllowOther))
{
warn!("Given auto_unmount without allow_root or allow_other; adding allow_other, with userspace permission handling");
let mut modified_options = options.to_vec();
modified_options.push(MountOption::AllowOther);
Mount::new(mountpoint, &modified_options)?
} else {
Mount::new(mountpoint, options)?
};
Aha, I think, and add AllowRoot in main.rs.
And ... it still fails with the same error???
A little bit of digging later, I see, in mountoptions.rs:
// Format option to be passed to libfuse or kernel
pub fn option_to_string(option: &MountOption) -> String {
match option {
// [...]
MountOption::AllowOther => "allow_other".to_string(),
// AllowRoot is implemented by allowing everyone access and then restricting to
// root + owner within fuser
MountOption::AllowRoot => "allow_other".to_string(),
// [...]
}
}
So the only option (besides setting 'user_allow_other' in /etc/fuse.conf) is to remove AutoUnmount from main.rs. Which is added unconditionally, despite AllowOther being behind a check of fuse_allow_other_enabled.
Of course this is a trivial issue, just wanted to report it. please feel free to close it.
I have just hit this issue. The docs for 0.15.1 of fuser state:
AutoUnmount Automatically unmount when the mounting process exits
AutoUnmount requires AllowOther or AllowRoot. If AutoUnmount is set and neither Allow... is set, the FUSE configuration must permit allow_other, otherwise mounting will fail.
I would like to enable AutoUnmount by enabling AllowRoot without enabling AllowOther - as I want to have the filesystem be unmounted when my application exits. I'd like to avoid adding AllowOther (which this seems to be under the covers).
Is this possible, or impossible due to an underlying fuse limitation?
If not possible, would be worth updating the docs to make this restriction clear.
I was doing some vibe coding with my friendly neighborhood LLM because I'm a baby Rustacean who can barely mutate a reference, and we got stuck on this. Essentially, there's nothing in IDE to tell us that the two options are related. Setting Auto without explicitly setting Allow should generate a warning, otherwise the subsequent error makes no sense. (does it generate a warning? I don't know. my project is currently generating a lot of warnings). On the other hand... if the options are set at runtime, how can the compiler catch it? a puzzle that's truly beyond the reach of my claws.
Adding AllowOther automatically when AutoUnmount is specified seems like a fairly dangerous default to me. AllowOther has potential security implications and the developer should really specify it explicitly so that they are aware the security implications are there. I would rather get an error if I specify AutoUnmount without AllowOther instead of the current automatic behavior.
PS: I know there is a warning logged when AllowOther is automatically added, but this warning does not show up if you don't have logging configured. In production it is quite likely that you either don't have logging configured or don't check the logs unless something breaks, making it easy to miss this warning.
Ya, this should be fixed. It looks like libfuse has special handling for this case: https://github.com/libfuse/libfuse/commit/055478f11dd4f3d46653f89ffe63f7c5a400b114