umask option not working about sshfs-win

[billziss-gh]

WinFsp 2018.1 B3 is out and includes create_umask. Please try it out and report back.

[billziss-gh]

Ok, I will file an enhancement request for a create_umask option in the WinFsp-FUSE layer and close this. I think other FUSE file systems could benefit from this feature.

[billziss-gh]

A fix for this has been included in WinFsp and will be available in the next beta (2018.1 B3).

[billziss-gh]

The umask option under FUSE does not work like umask under the normal UNIX prompt. Under FUSE if you set umask=022 you will get a file mode of 755, regardless of what the original file mode is on the remote file system.

I understand that this is counter-intuitive. However I believe the WinFsp-FUSE (and consequently SSHFS-Win) implementation to be correct. Here is how LIBFUSE (the reference FUSE implementation) does it:

https://github.com/libfuse/libfuse/blob/fuse-2_9_bugfix/lib/fuse.c#L1386-L1388

[xelra]

I didn't mean the permissions on the local system. On Windows those don't really make sense anyway. What I meant were the permissions on the remote system.

After playing around with the umask option, I realized that those "more or less" only affect the local permissions.

What I expect though, when mounting an SSHFS remote, is changing the permissions of files which I create.

For example, I mounted my remote and then I created a file. When I check the file on the remote machine, it always has permissions of 0700. It is there on the remote though, where I would like directories to have 0755 and newly created files to have 0644, when setting a umask of 0022.

[billziss-gh]

I didn't mean the permissions on the local system. On Windows those don't really make sense anyway. What I meant were the permissions on the remote system.

Actually under WinFsp the permissions bits are honored to the extent that it is possible. There is a very elaborate scheme that maps POSIX permissions to Windows ACL's and vice-versa. It is by no means perfect or complete, but it works in many cases.

The scheme is compatible with the one used by Cygwin and Microsoft's Services For UNIX.

After playing around with the umask option, I realized that those "more or less" only affect the local permissions.

Correct.

In general I find little reason to use it with SSHFS unless I need to force permissions (as seen by the local OS) for some reason (e.g. to allow access to additional users).

What I expect though, when mounting an SSHFS remote, is changing the permissions of files which I create.

I believe that the umask for newly created files is controlled by the SFTP server and not the client. My understanding is that the client does not have the ability to send the umask on the SFTP server. See, for example, this (unaccepted) stackoverflow answer which describes how to set the umask on the server.

[xelra]

I had a look at the stackoverflow article and tried the suggestions there without any effect. Then I went to the OpenSSH IRC channel and discussed this issue.

We tested a multitude of scenarios and also Linux sshfs/fuse and apparently the sshfs mount simply creates the file on the remote with the local (system-wide) umask. The same permission that a locally created file would have. Albeit with one exception - the other bit is always 0. Only user and group bits are used.
Here are a few examples to better clarify the behavior.

umask 022
touch file
ssh [email protected]
ls -l file
-rw-r-----   1 user  user     0 Oct  5 00:00 file

umask 222
touch file
ssh [email protected]
ls -l file
-r--r-----   1 user  user     0 Oct  5 00:00 file

umask 077
touch file
ssh [email protected]
ls -l file
-rw-------   1 user  user     0 Oct  5 00:00 file

umask 077
mkdir testdir
ssh [email protected]
ls -l
drwx------   1 user  user     4.0K Oct  5 00:00 testdir

umask 022
mkdir testdir
ssh [email protected]
ls -l
drwxr-x---   1 user  user     4.0K Oct  5 00:00 testdir

As you can see from the examples, the behavior mirrors the local umask setting with execute bits for directories and no execute bits for files. The "other" bits are ignored (for whatever reason, we couldn't find out why. Maybe it has something to do with allow_other).

Since Windows doesn't have this concept of umask and POSIX permissions though, I feel like SSHFS-Win will probably need to simulate the local umask.
SSHFS-Win would only result in 700 permission for both files and directories that are newly created.

[billziss-gh]

umask 022
touch file
ssh [email protected]
ls -l file
-rw-r-----   1 user  user     0 Oct  5 00:00 file

Looking at your example I am not sure I quite understand it. You set the umask, then touch the file and then list it. I am assuming that you are doing this on a (Linux?) SSHFS mount. But what is the ssh command doing in there?

I am looking into this more and I think it is normal Windows behavior:

• On POSIX when a program creates a file it usually uses 0666 (or DEFFILEMODE) and it relies on the umask to remove inappropriate bits. Hence you may get the usual 0644.

• On Windows when a program creates a file it usually uses the NULL (or default) security descriptor. This instructs the file system to use an ACL that only includes the file creator. When this gets translated into POSIX permissions you get 0700. Not much we can do about this other than create a new option in SSHFS that allows one to hardcode the "create" umask (i.e. what the FUSE umask option should probably have been in FUSE). Something along the lines of -o create_umask=022.

• On Cygwin (where there is a concept of umask) this actually works the same way as in Linux:

  billziss@windows:/cygdrive/y$ umask                       
  0022                                                      
  billziss@windows:/cygdrive/y$ echo hello>world            
  billziss@windows:/cygdrive/y$ ls -l world                 
  -rw-r--r-- 1 billziss NETWORK SERVICE 6 Oct  5 14:57 world
  

[xelra]

Looking at your example I am not sure I quite understand it. You set the umask, then touch the file and then list it. I am assuming that you are doing this on a (Linux?) SSHFS mount. But what is the ssh command doing in there?

Yes, it's on Linux. umask is on the local machine inside the root path of the sshfs mount. Then touch a file or mkdir. Then ssh into the remote machine and ls -l to check the permissions on the remote machine.

Not much we can do about this other than create a new option in SSHFS that allows one to hardcode the "create" umask.

Yes, I thought the same. It's simply an "incompatibility" between POSIX and Windows. The only other option would be to hijack Cygwin's umask, but I think that will be much more complicated and only lead to confusion and complexity.

[Shaddoh]

Hello Bill,
I am having the same issue as described above. I have umask set on the server. And when i Have the clients mounted through the ssh commands. Any file or folder they create is creating as 700. So then when someone else tries to access it they can not. I can of course go back to the server and chmod 777 the trouble directories but I am under the impression when the mount happens it should at the very least assume the global umask security settings. Unless I am way off base and each user has its own umask settings set somewhere. I am using linux centos 6 server and various windows client machines.
Thank you in advance.

[billziss-gh]

My apologies. This has fallen off my radar. I just added a new issue in WinFsp to track it and will close this.