Return to Answer

The solution was very vague on whether neither of the options, one of the options or both of the options should be used. Also split up a long paragraph.

Source Link

edit approved Nov 17, 2022 at 16:55

Karl Essinger

The question was answered in a linux mailing list; I post a translated answer here for completeness.

Solution

The solution is not to usednot use both of the options default_permissions and allow_other when mounting (which I didn't try in my original experiments).

Explanation

The problem seems to be quite simple. When you giveuse the option default_permissions in fusermount then fuse's permission control of the fuse mount is handled by the kernel and not by fuse.

This means that the REMOTE_USER's uid/gid aren't mapped to the LOCAL_USER (sshfs.c IDMAP_NONE). It works the same way as a simple nfs fs without mapping.

So, it makes sense to prohibit the access, if the uid/gid numbers don't match.

If you have the option allow_other then this dir is writable only by the local user with uid 699, if it exists.

From fuse's man:

'default_permissions' By default FUSE doesn't check file access permissions, the filesystem is free to implement its access policy or leave it to the underlying file access mechanism (e.g. in case of network filesystems). This option enables permission checking, restricting access based on file mode. It is usually useful together with the 'allow_other' mount option. 'allow_other' This option overrides the security measure restricting file access to the user mounting the filesystem. This option is by default only allowed to root, but this restriction can be removed with a (userspace) configuration option.

The question was answered in a linux mailing list; I post a translated answer here for completeness.

Solution

The solution is not to used both the options default_permissions and allow_other (which I didn't try in my original experiments).

Explanation

The problem seems to be quite simple. When you give the option default_permissions in fusermount then fuse's permission control of the fuse mount is handled by the kernel and not by fuse. This means that the REMOTE_USER's uid/gid aren't mapped to the LOCAL_USER (sshfs.c IDMAP_NONE). It works the same way as a simple nfs fs without mapping.

So, it makes sense to prohibit the access, if the uid/gid numbers don't match.

If you have the option allow_other then this dir is writable only by the local user with uid 699, if it exists.

From fuse's man:

'default_permissions' By default FUSE doesn't check file access permissions, the filesystem is free to implement its access policy or leave it to the underlying file access mechanism (e.g. in case of network filesystems). This option enables permission checking, restricting access based on file mode. It is usually useful together with the 'allow_other' mount option. 'allow_other' This option overrides the security measure restricting file access to the user mounting the filesystem. This option is by default only allowed to root, but this restriction can be removed with a (userspace) configuration option.

The question was answered in a linux mailing list; I post a translated answer here for completeness.

Solution

The solution is to not use both of the options default_permissions and allow_other when mounting (which I didn't try in my original experiments).

Explanation

The problem seems to be quite simple. When you use the option default_permissions in fusermount then fuse's permission control of the fuse mount is handled by the kernel and not by fuse.

This means that the REMOTE_USER's uid/gid aren't mapped to the LOCAL_USER (sshfs.c IDMAP_NONE). It works the same way as a simple nfs fs without mapping.

So, it makes sense to prohibit the access, if the uid/gid numbers don't match.

If you have the option allow_other then this dir is writable only by the local user with uid 699, if it exists.

From fuse's man:

'default_permissions' By default FUSE doesn't check file access permissions, the filesystem is free to implement its access policy or leave it to the underlying file access mechanism (e.g. in case of network filesystems). This option enables permission checking, restricting access based on file mode. It is usually useful together with the 'allow_other' mount option. 'allow_other' This option overrides the security measure restricting file access to the user mounting the filesystem. This option is by default only allowed to root, but this restriction can be removed with a (userspace) configuration option.

Source Link

answered May 13, 2016 at 8:26

vkats

The question was answered in a linux mailing list; I post a translated answer here for completeness.

Solution

The solution is not to used both the options default_permissions and allow_other (which I didn't try in my original experiments).

Explanation

So, it makes sense to prohibit the access, if the uid/gid numbers don't match.

If you have the option allow_other then this dir is writable only by the local user with uid 699, if it exists.

From fuse's man:

'default_permissions' By default FUSE doesn't check file access permissions, the filesystem is free to implement its access policy or leave it to the underlying file access mechanism (e.g. in case of network filesystems). This option enables permission checking, restricting access based on file mode. It is usually useful together with the 'allow_other' mount option. 'allow_other' This option overrides the security measure restricting file access to the user mounting the filesystem. This option is by default only allowed to root, but this restriction can be removed with a (userspace) configuration option.