Closed jeaneric closed 3 years ago
The Everyone special permissions that should be remove can be see with advance option:
Rclone doesn't support setting individual permissions for files at the moment.
Is your workaround good enough?
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.
@jeaneric Can you confirm the bug in WinFSP? Did you report to https://github.com/billziss-gh/winfsp ?
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.
Thank you for responding
Waiting for upstream PR https://github.com/billziss-gh/winfsp/pull/331
Please see my answer in billziss-gh/winfsp#331 where I propose an alternative to overcome this problem.
@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.
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.
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):
-o FileSecurity="D:P(A;;FA;;;<your-SID>)"
. This will set an ACL with a single "allow" entry, allowing all file access (FA
) for the account with SID <your-SID>
(replace your own SID here). The WinFsp-FUSE layer will combine this ACL with the owner/group information from the -o uid=UID,gid=GID
options and use this as the security descriptor for all files. -o FileSecurity="D:P(A;;FA;;;CO)"
. Like before except "nicer" (if it works). This gives all file access (FA
) to the "Creator/Owner" account, which is the account that owns the file.
AccessCheck
API. I am unclear if AccessCheck
supports "Creator/Owner".-o uid=-1,FileSecurity="D:P(A;;FA;;;CO)"
Just to let people know that I have released WinFsp 2021 Beta2, which includes the discussed FileSecurity
option:
@billziss-gh Thanks a lot for making this append. It now works. Here are the details:
-o FileSecurity="D:P(A;;FA;;;CO)"
-o FileSecurity="D:P(A;;FA;;;<your-SID>)";
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:
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!
@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
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.
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:
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.
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.
And the real problem I have is when I use the files that are ssh key in visual studio code I have this error:
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