Ssh – set umask for sshfs-mounted filesystem

filesystemsmountpermissionssshfsumask

I have a remote sshfs filesystem mounted on /mnt/data. Following is the relevant line in /etc/fstab:

www-data@192.168.1.10:/var/www/ /mnt/data       fuse.sshfs   rw,noauto,nodev,nosuid,noexec,_netdev,allow_other,default_permissions,uid=martin,gid=martin    0   0

The files in /var/www/ on the remote system are owned by user www-data, but I am using uid=martin,gid=martin to map the ownership on the mounted filesystem to uid 1000.

When I cd to /mnt/data/ as martin, I have the correct file permissions/ownership, but I need to change the umask.

On the remote filesytem, the user www-data has umask 0027. On my local filesystem, the user martin has umask 0077. I want to keep the umask 0077 on my local files, but use 0027 on the sshfs mounted files (ie all files in /mnt/data/).

Is this even possible ?

I have tried setting acl permissions on the whole directory on the remote filesystem:

setfacl -d -m g::rx  /var/www/
setfacl -d -m o::--- /var/www/

but this has no effect on the sshfs mounted share.

Best Answer

sshfs is using sftp under the hood and the umask for creation new files is handled by the remote sftp-server. You can set umask as an argument to the sftp-server in /etc/ssh/sshd_config on the server, such as

Subsystem sftp /usr/lib/openssh/sftp-server -u 027     # Debian/Ubuntu

Subsystem sftp /usr/libexec/openssh/sftp-server -u 027 # RHEL/Fedora

Subsystem sftp /usr/lib/ssh/sftp-server -u 027         # Arch

The umask settings and extended ACL are not transferred through the SFTP protocol as implemented by openssh. Also note that there is no "umask on files", but umask is always associated with running process creating the files.

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.

Best Answer

Related Solutions

Ssh – UID/GID with sshfs of Linux FUSE

SSHFS – Mount with Write File Permissions

Solution

Explanation

Related Question