rclone / rclone

"rsync for cloud storage" - Google Drive, S3, Dropbox, Backblaze B2, One Drive, Swift, Hubic, Wasabi, Google Cloud Storage, Azure Blob, Azure Files, Yandex Files
https://rclone.org
MIT License
45.94k stars 4.11k forks source link

Permissions on mount (Windows 10) #4717

Closed jeaneric closed 3 years ago

jeaneric commented 3 years ago

I'm mounting a remote(in fact an local encrypted one) to my file system. rclone mount --config ./file.txt --file-perms 700 --dir-perms 700 --default-permissions --vfs-cache-mode full encrypt-remote: C:\...\foldername

This works fine. I have access to the files and the permissions looks almost ok, but "Everyone" seems to get some permissions not specified! The 700 works ok and the permission (read-wirte) is really only to my current user which is fine.

image

And the real problem I have is when I use the files that are ssh key in visual studio code I have this error:

image

I tried to change them permissions, to remove the everyone entry, but not working (no error but when reopening the properties, it's still there). I also tried to mount on a separate drive (X:) but same problem.

My best guest is that the "Everyone" entry in the security of the file cause the problem. I've tried various option, none were successful to remove it. Can it be removed?

System

rclone-v1.53.2-windows-amd64 Windows 10 VS Code 1.50.1

jeaneric commented 3 years ago

Update

The Everyone special permissions that should be remove can be see with advance option: image

ncw commented 3 years ago

Rclone doesn't support setting individual permissions for files at the moment.

Is your workaround good enough?

jeaneric commented 3 years ago

I'm not trying to set individual permissions, those screenshot are just for one file directly after the mount.

What I want is that the 700 mask I set is respected (which is not the case at the moment) and that everyone and group have no permissions at all. We can see see that with the screenshot that they still have some very basic permissions.

But I think that I found the problem in winfsp. I will keep this thread update.

ivandeex commented 3 years ago

@jeaneric Can you confirm the bug in WinFSP? Did you report to https://github.com/billziss-gh/winfsp ?

jeaneric commented 3 years ago

I can confirm it come from winfsp. I made a pull request, but not filled a bug.... I haven't had any news from the pull request. The pull request solved the bug in my test machine.

ivandeex commented 3 years ago

Thank you for responding

Waiting for upstream PR https://github.com/billziss-gh/winfsp/pull/331

billziss-gh commented 3 years ago

Please see my answer in billziss-gh/winfsp#331 where I propose an alternative to overcome this problem.

ivandeex commented 3 years ago

@ncw As announced in https://github.com/billziss-gh/winfsp/pull/331#issuecomment-767213477, a future WinFSP release will add (https://github.com/billziss-gh/winfsp/commit/9d5efe5f988e92d63564bbbec1aadaa38d5e0275) new FileSecurity option giving users more fine-grained control over mount permissions on Windows using SDDL string syntax. If that does not fit in the current set of options we will need a new command-line argument.

ncw commented 3 years ago

I think this should be usable immediately from within rclone by adding -o FileSecurity=SDDL to the rclone mount command line when the relevant WinFSP is released.

@jeaneric can you confirm this fixes your issue? And what SDDL string do you need? That should probably go in the rclone docs.

billziss-gh commented 3 years ago

You can use the fsptool utility that ships with WinFsp to discover SDDL strings to use. For example:

billziss@xps:~> . 'C:\Program Files (x86)\WinFsp\bin\fsptool-x64.exe' id
User=S-1-5-21-3594359382-1798744555-2422960822-1001(XPS\billziss) (uid=197609)
Owner=S-1-5-21-3594359382-1798744555-2422960822-1001(XPS\billziss) (uid=197609)
Group=S-1-5-21-3594359382-1798744555-2422960822-513(XPS\None) (gid=197121)
billziss@xps:~> . 'C:\Program Files (x86)\WinFsp\bin\fsptool-x64.exe' perm 197609:0:700
O:S-1-5-21-3594359382-1798744555-2422960822-1001G:S-1-5-0D:P(A;;0x1f01bf;;;S-1-5-21-3594359382-1798744555-2422960822-1001)(A;;0x120088;;;S-1-5-0)(A;;0x120088;;;WD) (perm=197609:0:0700)

Here I use the command fsptool id to find my accounts SID and (mapped UNIX) UID. Then I use the command fsptool perm UID:0:700 to ask for the SDDL for my account's UID with a 0 GID and permissions rwx------ in octal.

However I recommend the following simpler SDDL's (untested -- please use these as a starting point):

billziss-gh commented 3 years ago

Just to let people know that I have released WinFsp 2021 Beta2, which includes the discussed FileSecurity option:

https://github.com/billziss-gh/winfsp/releases

jeaneric commented 3 years ago

@billziss-gh Thanks a lot for making this append. It now works. Here are the details:

So in .bat file, I'm doing something like that to avoid hard code the user SID:

@REM https://stackoverflow.com/a/30117236/140384
for /F "tokens=2" %%i in ('whoami /user /fo table /nh') do set usersid=%%i
rclone mount -o FileSecurity="D:P(A;;FA;;;%usersid%)" --vfs-cache-mode full encrypt-remote: C:\...\foldername

Now Only my user has rights to the file: image

jeaneric commented 3 years ago

For reference to everyone interested, I wanted that functionality to have an encrypted folder in my cloud storage that holds my private ssh keys. Them I mount this folder to my .ssh user folder which allow me to not store in clear ssh keys on my computer. The security on the mount is necessary as for best practice, ssh ensure that only you can see the ssh key you are using. Now it's working!

billziss-gh commented 3 years ago

@jeaneric I am glad that this works for you.

Unfortunately the CO (CREATOR_OWNER) seems to only be used for inheritable ACLs and not taken into account when using the AccessCheck API.

There is a chance that an alternative SID that represents the owner of the file can be used: OW (OWNER_RIGHTS). So if you have the time try also this SDDL: -o FileSecurity="D:P(A;;FA;;;OW)"

BTW, I am looking at this list of “Well-known SIDs” to find one that could be used to specify the owner of the file without having to restate the SID explicitly: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/81d92bba-d22b-4a8c-908a-554ab29148ab

billziss-gh commented 3 years ago

I just tried this myself and the good news are that it works.

I used the following option: -o uid=-1,gid=-1,FileSecurity="D:P(A;;FA;;;OW)"

This gives files the following SDDL:

billziss@xps:X:\> . "C:\Program Files (x86)\WinFsp\bin\fsptool-x64.exe" perm X:\
O:S-1-5-21-3594359382-1798744555-2422960822-1001G:S-1-5-21-3594359382-1798744555-2422960822-513D:P(A;;FA;;;OW) (perm=197609:197121:0000)

I tested against the sample FUSE file system memfs-fuse3 (included with WinFsp). In my limited testing security appears to work properly: my account was able to access the files for read/write, but other accounts (including the SYSTEM account) were unable to.

jeaneric commented 3 years ago

The option -o uid=-1,gid=-1,FileSecurity="D:P(A;;FA;;;OW)" , does not seems to work on my side.

The Windows interface says, never saw something like that, but I'm not an expert: image

But the proprietary of the file is me... so looks ok, but when I try editing files it does not work.... I haven't made a lot of test.

And the results for the 2 options with "C:\Program Files (x86)\WinFsp\bin\fsptool-x64.exe" perm are not the same for me.

-o uid=-1,gid=-1,FileSecurity="D:P(A;;FA;;;OW)"
O:S-1-5-21-790525478-1284227242-1417001333-123456G:DUD:P(A;;FA;;;OW) (perm=1482967:1049089:0000)
-o FileSecurity="D:P(A;;FA;;;%usersid%)"
O:S-1-5-21-790525478-1284227242-1417001333-123456G:DUD:P(A;;FA;;;S-1-5-21-790525478-1284227242-1417001333-123456) (perm=1482967:1049089:0700)

Both after using rclone mount.