fuser icon indicating copy to clipboard operation
fuser copied to clipboard

[minor] The way AllowOther is handled is confusing

Open 0x53A opened this issue 1 year ago • 4 comments

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.

0x53A avatar Nov 25 '24 23:11 0x53A

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.

piersfinlayson avatar Jan 07 '25 14:01 piersfinlayson

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.

rarensu avatar Apr 23 '25 00:04 rarensu

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.

FeldrinH avatar Nov 27 '25 15:11 FeldrinH

Ya, this should be fixed. It looks like libfuse has special handling for this case: https://github.com/libfuse/libfuse/commit/055478f11dd4f3d46653f89ffe63f7c5a400b114

cberner avatar Nov 27 '25 19:11 cberner