User group related permission issues on Windows 10

[fincs]

I have some weird issues related to filesystem permissions. I'm trying to use securefs. However, when I mount a folder using the latest version of securefs (0.8.2), the resulting filesystem is read only and I cannot create or modify any files. If I mount it with 0.7.3 (which is the last version that has worked for me), I get proper read/write access. Going by the commit log, I suspect a commit which changed uid/gid management is the culprit; however it doesn't look like anyone else using securefs on Windows has this problem so it must somehow be on my end. This led me to investigate using fsptool. The output of fsptool id is as follows (some data censored):

User=S-1-5-21-9999999999-9999999999-9999999999-1001(COMPUTERNAME\fincs) (uid=197609)
Owner=S-1-5-21-9999999999-9999999999-9999999999-1001(COMPUTERNAME\fincs) (uid=197609)
Group=S-1-5-21-9999999999-9999999999-9999999999-1001(COMPUTERNAME\fincs) (gid=197609)

I find it very weird that my Group SID is the same as my User SID. I think that's somehow wrong - I've tried running fsptool id on a fresh and clean Windows VM and the Group SID is different from the User SID. If it helps, my account has admin rights and it is also logged in to a MS account.

I also checked the output of fsptool perm N:\ (where N is the drive letter I used with securefs). 0.8.2 produces this:

O:S-1-5-21-9999999999-9999999999-9999999999-1001G:S-1-5-21-9999999999-9999999999-9999999999-1001D:P(A;;0x1f01b9;;;S-1-5-21-9999999999-9999999999-9999999999-1001)(A;;0x1200a9;;;S-1-5-21-9999999999-9999999999-9999999999-1001)(A;;0x1200a9;;;WD) (perm=197609:197609:0555)

On the other hand, 0.7.3 produces this:

O:S-1-5-21-9999999999-9999999999-9999999999-1001G:MED:P(A;;FA;;;S-1-5-21-9999999999-9999999999-9999999999-1001)(A;;0x1200a9;;;ME)(A;;0x1200a9;;;WD) (perm=197609:401408:0755)

Note how on 0.8.2 uid/gid match, but on 0.7.3 I get a proper gid (corresponding to S-1-16-8192 "Medium Mandatory Level") that is different from my uid and different permissions as well. EDIT: Seems like securefs 0.7.3 used GetTokenInformation(TokenGroups) to get the group SID (concretely it used the first SID in the returned array); but fsptool is using TokenPrimaryGroup instead. MSDN documents as follows:

Name	Description
TokenGroups	The buffer receives a TOKEN_GROUPS structure that contains the group accounts associated with the token.
TokenPrimaryGroup	The buffer receives a TOKEN_PRIMARY_GROUP structure that contains the default primary group SID for newly created objects.

It looks to me like TokenPrimaryGroup isn't what it seems; there doesn't seem to be the concept of a primary group for Windows users. I did some googling and it seems like "primary group" only exists in Active Directory which is a Windows Server only service. TokenPrimaryGroup also gets used in several places inside WinFsp.

Finally, I also tried using sshfs to connect to a Linux box. I could see the root of its filesystem but I didn't seem to have any sort of access to /home/fincs (and I logged in as fincs), I couldn't even list its contents. Of course it works just fine if I use normal ssh or even something like FileZilla.

EDIT: memfs seems to work just fine.

I don't know what else to investigate. I don't know if this is some sort of configuration issue on my end, or if this is possibly a bug in WinFsp.

Environment

• Windows 10 Pro 1809 x64 (Version 10.0.17763.165)
• WinFsp version 2018.2 B3 (Originally I was using stable 2018.1, I tried upgrading to see if it would help but that didn't work)

Output of diag.bat

WINFSP INSTALLATION DIRECTORY AND LAUNCHER REGISTRATIONS

HKEY_LOCAL_MACHINE\SOFTWARE\WinFsp
    InstallDir    REG_SZ    C:\Program Files (x86)\WinFsp\

HKEY_LOCAL_MACHINE\SOFTWARE\WinFsp\Services

HKEY_LOCAL_MACHINE\SOFTWARE\WinFsp\Services\memfs-dotnet
    Executable    REG_SZ    C:\Program Files (x86)\WinFsp\bin\memfs-dotnet-msil.exe
    CommandLine    REG_SZ    -i -F NTFS -n 65536 -s 67108864 -u %1 -m %2
    Security    REG_SZ    D:P(A;;RPWPLC;;;WD)
    JobControl    REG_DWORD    0x1

HKEY_LOCAL_MACHINE\SOFTWARE\WinFsp\Services\memfs32
    Executable    REG_SZ    C:\Program Files (x86)\WinFsp\bin\memfs-x86.exe
    CommandLine    REG_SZ    -i -F NTFS -n 65536 -s 67108864 -u %1 -m %2
    Security    REG_SZ    D:P(A;;RPWPLC;;;WD)
    JobControl    REG_DWORD    0x1

HKEY_LOCAL_MACHINE\SOFTWARE\WinFsp\Services\memfs64
    Executable    REG_SZ    C:\Program Files (x86)\WinFsp\bin\memfs-x64.exe
    CommandLine    REG_SZ    -i -F NTFS -n 65536 -s 67108864 -u %1 -m %2
    Security    REG_SZ    D:P(A;;RPWPLC;;;WD)
    JobControl    REG_DWORD    0x1

HKEY_LOCAL_MACHINE\SOFTWARE\WinFsp\Services\sshfs
    Executable    REG_SZ    C:\Program Files\SSHFS-Win\bin\sshfs-win.exe
    CommandLine    REG_SZ    %1 %2 %U
    Security    REG_SZ    D:P(A;;RPWPLC;;;WD)
    JobControl    REG_DWORD    0x1
    Credentials    REG_DWORD    0x1


WINFSP DLL REGISTRATIONS

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order
    ProviderOrder    REG_SZ    WinFsp.Np,RDPNP,LanmanWorkstation,webclient


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinFsp.Np\NetworkProvider
    Name    REG_SZ    Windows File System Proxy
    ProviderPath    REG_SZ    C:\Program Files (x86)\WinFsp\bin\winfsp-x64.dll
    DeviceName    REG_SZ    \Device\WinFsp.Mup


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application\WinFsp
    EventMessageFile    REG_SZ    C:\Program Files (x86)\WinFsp\bin\winfsp-x64.dll
    TypesSupported    REG_DWORD    0x7


WINFSP FSD CONFIGURATION AND STATUS

SERVICE_NAME: WinFsp
        TYPE               : 2  FILE_SYSTEM_DRIVER
        STATE              : 4  RUNNING
                                (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0
[SC] QueryServiceConfig SUCCESS

SERVICE_NAME: WinFsp
        TYPE               : 2  FILE_SYSTEM_DRIVER
        START_TYPE         : 3   DEMAND_START
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : \??\C:\Program Files (x86)\WinFsp\bin\winfsp-x64.sys
        LOAD_ORDER_GROUP   :
        TAG                : 0
        DISPLAY_NAME       : WinFsp
        DEPENDENCIES       :
        SERVICE_START_NAME :

D:(A;;LCRP;;;WD)(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)

WINFSP LAUNCHER SERVICE CONFIGURATION AND STATUS

SERVICE_NAME: WinFsp.Launcher
        TYPE               : 10  WIN32_OWN_PROCESS
        STATE              : 4  RUNNING
                                (STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0
[SC] QueryServiceConfig SUCCESS

SERVICE_NAME: WinFsp.Launcher
        TYPE               : 10  WIN32_OWN_PROCESS
        START_TYPE         : 2   AUTO_START
        ERROR_CONTROL      : 0   IGNORE
        BINARY_PATH_NAME   : "C:\Program Files (x86)\WinFsp\bin\launcher-x64.exe"
        LOAD_ORDER_GROUP   :
        TAG                : 0
        DISPLAY_NAME       : WinFsp.Launcher
        DEPENDENCIES       :
        SERVICE_START_NAME : LocalSystem

D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)

OS INFORMATION

Host Name:                 COMPUTERNAME
OS Name:                   Microsoft Windows 10 Pro
OS Version:                10.0.17763 N/A Build 17763
OS Manufacturer:           Microsoft Corporation
OS Configuration:          Standalone Workstation
OS Build Type:             Multiprocessor Free
(..snip..)
System Type:               x64-based PC
Processor(s):              1 Processor(s) Installed.
                           [01]: Intel64 Family 6 Model 60 Stepping 3 GenuineIntel ~4001 Mhz
(..snip..)
Windows Directory:         C:\WINDOWS
System Directory:          C:\WINDOWS\system32
Boot Device:               \Device\HarddiskVolume2
(..snip..)
Total Physical Memory:     16,327 MB
Available Physical Memory: 11,397 MB
Virtual Memory: Max Size:  17,351 MB
Virtual Memory: Available: 11,420 MB
Virtual Memory: In Use:    5,931 MB
Page File Location(s):     C:\pagefile.sys
Domain:                    WORKGROUP
Logon Server:              \\COMPUTERNAME
Hotfix(s):                 7 Hotfix(s) Installed.
                           [01]: KB4462930
                           [02]: KB4465477
                           [03]: KB4465664
                           [04]: KB4467694
                           [05]: KB4470788
                           [06]: KB4477029
                           [07]: KB4469342
(..snip..)
Hyper-V Requirements:      VM Monitor Mode Extensions: Yes
                           Virtualization Enabled In Firmware: Yes
                           Second Level Address Translation: Yes
                           Data Execution Prevention Available: Yes

[fincs]

I wrote a small program to print the contents of both TokenPrimaryGroup and TokenGroups; and ran it on both my computer and on my Windows (7) VM. Here are the results:

Computer:

"primary" group: sid: S-1-5-21-9999999999-9999999999-9999999999-1001 (COMPUTERNAME\fincs)
group 0: attrib 60, sid: S-1-16-8192 (Mandatory Label\Medium Mandatory Level)
group 1: attrib 7, sid: S-1-1-0 (Everyone)
group 2: attrib 10, sid: S-1-5-114 (NT AUTHORITY\Local account and member of Administrators group)
group 3: attrib 7, sid: S-1-5-21-9999999999-9999999999-9999999999-1002 (COMPUTERNAME\HomeUsers)
group 4: attrib 7, sid: S-1-5-21-9999999999-9999999999-9999999999-1010 (COMPUTERNAME\Ssh Users)
group 5: attrib 10, sid: S-1-5-32-544 (BUILTIN\Administrators)
group 6: attrib 7, sid: S-1-5-32-559 (BUILTIN\Performance Log Users)
group 7: attrib 7, sid: S-1-5-32-545 (BUILTIN\Users)
group 8: attrib 7, sid: S-1-5-4 (NT AUTHORITY\INTERACTIVE)
group 9: attrib 7, sid: S-1-2-1 (CONSOLE LOGON)
group 10: attrib 7, sid: S-1-5-11 (NT AUTHORITY\Authenticated Users)
group 11: attrib 7, sid: S-1-5-15 (NT AUTHORITY\This Organization)
group 12: attrib 7, sid: S-1-11-96-9999999999-99999-99999-9999999999-9999999999-9999999999-9999999999-9999999999-9999999999-9999999999 (MicrosoftAccount\some_email_address@hotmail.com)
group 13: attrib 7, sid: S-1-5-113 (NT AUTHORITY\Local account)
group 14: attrib c0000007, sid: S-1-5-5-0-215909 (NT AUTHORITY\LogonSessionId_0_215909)
group 15: attrib 7, sid: S-1-2-0 (LOCAL)
group 16: attrib 7, sid: S-1-5-64-36 (NT AUTHORITY\Cloud Account Authentication)

VM:

"primary" group: sid: S-1-5-21-9999999999-9999999999-9999999999-513 (fincs-win7vm\None)
group 0: attrib 7, sid: S-1-5-21-9999999999-9999999999-9999999999-513 (fincs-win7vm\None)
group 1: attrib 7, sid: S-1-1-0 (Everyone)
group 2: attrib 7, sid: S-1-5-21-9999999999-9999999999-9999999999-1000 (fincs-win7vm\HomeUsers)
group 3: attrib 10, sid: S-1-5-32-544 (BUILTIN\Administrators)
group 4: attrib 7, sid: S-1-5-32-545 (BUILTIN\Users)
group 5: attrib 7, sid: S-1-5-4 (NT AUTHORITY\INTERACTIVE)
group 6: attrib 7, sid: S-1-2-1 (CONSOLE LOGON)
group 7: attrib 7, sid: S-1-5-11 (NT AUTHORITY\Authenticated Users)
group 8: attrib 7, sid: S-1-5-15 (NT AUTHORITY\This Organization)
group 9: attrib c0000007, sid: S-1-5-5-0-95536 ()
group 10: attrib 7, sid: S-1-2-0 (LOCAL)
group 11: attrib 7, sid: S-1-5-64-10 (NT AUTHORITY\NTLM Authentication)
group 12: attrib 60, sid: S-1-16-8192 (Mandatory Label\Medium Mandatory Level)

Seems like on Windows 10, the "primary" group is not included within the list of groups, whereas on Windows 7 it does. For this reason I believe that's why I am not granted access to anything, because I don't actually belong to said "primary" group.

At this point I'm wondering if WinFsp could, instead of using TokenPrimaryGroup, somehow pick a group from the list returned by TokenGroups, and use that as the emulated POSIX primary group. I'm not sure which heuristic could be used for this task.

[billziss-gh]

@fincs apologies for the delay in response.

I am not certain why your UID and GID are the same. For example, on my own Windows 10 box I get:

billziss@windows:~$ /cygdrive/c/Program\ Files\ \(x86\)/WinFsp/bin/fsptool-x64.exe id
User=S-1-5-21-XXX-1001(WINDOWS\billziss) (uid=197609)
Owner=S-1-5-21-XXX-1001(WINDOWS\billziss) (uid=197609)
Group=S-1-5-21-XXX-513(WINDOWS\None) (gid=197121)

If your UID and GID are the same in a WinFsp-FUSE file system you can indeed have permission problems. This is because WinFsp always chooses the most restrictive permissions in this case:

https://github.com/billziss-gh/winfsp/blob/v1.4B3/src/dll/posix.c#L471-L478

It looks to me like TokenPrimaryGroup isn't what it seems; there doesn't seem to be the concept of a primary group for Windows users... At this point I'm wondering if WinFsp could, instead of using TokenPrimaryGroup, somehow pick a group from the list returned by TokenGroups, and use that as the emulated POSIX primary group. I'm not sure which heuristic could be used for this task.

You hit the nail on the head. There is no direct equivalent of "primary group" in Windows. So I struggled with the decision of whether to use TokenPrimaryGroup or TokenGroups and in the end I settled with TokenPrimaryGroup because I did not know which group to choose from TokenGroups.

If we could come up with a good heuristic I would consider changing it, but we would also have to consider any breakage for existing users that (implicitly) assume TokenPrimaryGroup.

[fincs]

Thank you for your response.

I'm also puzzled as to why my GID is the same as my UID, or in different words, why TokenPrimaryGroup returns my user's SID instead of a group I actually belong to. I'd like to think it's a configuration problem that I could solve (short of wiping my Windows installation and starting over), but I do not know where to look for clues.

As for the heuristic, securefs' old "use first element from TokenGroup array" approach worked for me. From what I saw with my test program, it looks like in "normal" circumstances the first group is going to match TokenPrimaryGroup anyway so users shouldn't be affected by it. Alternatively, we could use the highest (or lowest?) privilege built-in group the user belongs to.

[billziss-gh]

I think it would be beneficial to understand why on your system the user SID and the TokenPrimaryGroup SID are the same. For example, are there circumstances where the user SID also appears in the TokenGroups list (in which case our heuristic may also fail)?

[fincs]

I'd also like to figure out why my system has that behavior; however I'm not very familiar with the Windows security model and I need some pointers to look at. Could it be related to MS account login? What I can tell though is that "None" seems to be what the primary group of a token should be for our purposes. My user doesn't seem to be a member of "None" either.

Also, I haven't observed the user SID being included within the TokenGroups list at all, nor can I think of any reason why it would be there since it's not actually a real group SID. It probably wasn't worth a shot, but "Local Users and Groups" doesn't let me add non-group objects to the list of groups a user is a member of.

EDIT: Found the following info on "None":

SID	Display Name	Description
S-1-5-domain-513	Domain Users	A global group that includes all users in a domain. When you create a new User object in Active Directory, the user is automatically added to this group.

[billziss-gh]

I'd also like to figure out why my system has that behavior; however I'm not very familiar with the Windows security model and I need some pointers to look at.

Although I have a fairly good understanding of the Windows security model, unfortunately I do not have any good pointers either.

BTW, it should be possible to run the file system with -o uid=-1,gid=GID where GID can be a hardcoded number (e.g. 11 for Authenticated Users). Does this not work for securefs (e.g. because it disallows the specification of base FUSE options on the command line)?

[fincs]

Unfortunately, securefs hardcodes -ouid=-1,gid=-1 and doesn't allow me to use custom uid/gid. However, sshfs does allow me to do that and now I can access my files (!).

[billziss-gh]

Perhaps then the thing to do is to ask securefs for the capability to specify additional FUSE options (so that you could supply your own -o uid=UID,gid=GID to override the default ones -- if I am not mistaken specifying additional options would override prior ones).

[fincs]

On a closer look, they seem to have that feature already, but... the custom options get added before the hardcoded uid/gid and thus the hardcoded uid/gid take precedence. Still, this approach is only a workaround though.

[fincs]

I just had to perform a clean installation of Windows 10, and unfortunately the same exact problem described in the OP still applies. At this point I'm suspecting that being logged into a MS account might have something to do with it.

[billziss-gh]

@fincs thanks for the additional information.

I am currently busy with another Windows kernel project (WinSpd), but I am hoping to find a resolution for this in the next WinFsp release.

[fincs]

No problem. In the mean time I will continue using the workarounds described previously in this thread.

Also, thank you for pointing me towards WinSpd; I'm looking forward to it :)

[infeo]

I am wondering if this issue found its way into the 1.7 release? 😄

I have the same problem and can confirm that it only appears if you create a local account directly with your Microsoft account. Using the fsptool, it outputs the same value (my sid) for user and group. If you create a "normal" offline account and link it later to a Microsoft one, everything 's fine (edit: i was wrong).

As already stated, a workaround is to use a well-known SID like the "Authenticated Users".

[fincs]

For what it's worth, I always create an offline account first and only link it to my MS account afterwards; so that can't be the issue.

[richardb64]

Another confirmation that this is caused by the use of Microsoft accounts...

I had been using sshfs flawlessly for months. Then very recently, I linked the local account to a Microsoft account (reluctantly, but as the only way to protect my Windows licence from hardware failure in the "digital licence" world). From then on, sshfs hasn't been working at all - everything read-only, and other random effects.

Adding -ogid=xxxx, where xxxx is the group ID my account used to have before it was linked to Microsoft (shown in Cygwin as "None"), seems to have mostly fixed the problem. Using gid 545 ("Users") seems to work OK too. There's still an issue with one server, where my home directory isn't readable, though its contents is - I'll investigate that separately.

[billziss-gh]

I would like to see this problem fixed. Many users are not aware of the -ogid=GID workaround and are getting bitten by spurious permission problems.

The main problem that I have with this, is that all fixes that I can come up with are not satisfactory in some regard.

• If we relax/remove the permission check in FspPosixMapPermissionsToSecurityDescriptor, it is likely that it would break someone's security.

• If we change the way the GID is computed when -ogid=-1 is passed (e.g. to use TokenGroups instead of TokenPrimaryGroup as was discussed above), it is again likely that we would break someone's security.

  • Perhaps the thing to do here is only look in TokenGroups when TokenPrimaryGroup is the same as the user's SID. This is still dangerous, but perhaps less so?

• If we add a new command line switch to influence the change in behavior (thus getting around compatibility concerns) the user must know about the new command line switch and should presumably already know about the -ogid=GID workaround.

[richardb64]

I think it's necessary - somehow - to fix this in such a way that the end users don't have to do (or know) anything new, even if using FUSE at all suggests the audience is a bit more technical than the average!

Would it work to treat the OwnerSid==GroupSid case as if there were no group defined at all? ie. in constructing the effective Windows ACL, ignore the group permission bits altogether, and translate the (POSIX) User and Other permissions only. Or invert the logic, and if OwnerSid==GroupSid then make the effective Windows permissions the union (bitwise OR) rather than the intersection of the POSIX user and group perms.

Having user permissions be more restrictive than group permissions is technically allowed, but it's pretty niche and is surely hardly ever used in practice (except by mistake!). Also, even if Windows allows something, the server will reject the access if it clashes with the real permissions, so in practice getting the Windows ACL right is mainly for cosmetic and efficiency reasons, and isn't essential for security. In fact, the server might be willing to allow something that the basic POSIX permissions bits appear to disallow (eg. with ACLs server-side), and so perhaps it's best for WinFsp to err on the side of being relaxed and open.

Viewing the result in Cygwin or SFU (ie. with yet another heuristic layer mapping Windows ACLs back to a POSIX octal value) might be a bit odd, but again that's likely to be a cosmetic issue only.

(I know I've talked about "server" above, and FUSE isn't just for the remote filesystem use case... but is it reasonable to assume more generally that the WinFsp layer doesn't have to be too strict about security, because the lower layers are actually responsible for enforcing it?)

[marcello-pietrobon]

Hi, I too have a very similar problem with virtio-fs, as described in the link just given by StevenDoesStuffs. Actually I have tried everything with Samba and NFS and nothing has worked for me, so to fix WinFps as described here has become quite important, being quite probably that virtio-fs would then work as expected.

For now just a workaround would be enough for me, so I was wondering which one could be the best direction to take.

If I have well understood the launcher could call memfs-x64.exe with the option '-ogid=-1', Is that correct?

• if so, would it be possible, as a workaround, to just change in the Windows' registry the value of the 'CommandLine' key in
  HKLM\SOFTWARE\WOW6432Node\WinFsp\Services\memfs64
  and apply there the workaround '-ogid=-1' ?

• or, if not, would it be possible to compile the launcher so that it would launch memfs-x64.exe with the option '-ogid=-1' ?

• I imagine the best way would be to compile and fix the code of memfs-x64.exe itself as discussed above in this thread, I'd desire to try tomorrow.

any suggestion?

[billziss-gh]

The problem discussed in this issue is a problem that can happen with FUSE file systems only. (FUSE file systems are ones that were in general ported from Linux of macOS.)

MEMFS is not a FUSE file system and would not benefit from the -ogid=-1 option. In fact it does not recognize this command line option, because it is not a FUSE file system.

If you are using MEMFS it is likely that the issue you are experiencing is not related to the one discussed here.

[billziss-gh]

Please note that I have added a new FUSE command-line option -o FileSecurity=SDDL, which can be used to control the security descriptors that a FUSE file system returns for files. This functionality can be found in commit 9d5efe5 and will be available in the next beta release.

For some usage suggestions see this comment: rclone/rclone#4717 (comment)

While this does not directly address the problem raised in this issue, it gives another tool for working around it. Given that there are now multiple ways to work around this problem and that fixing it directly would break backwards compatibility, I will likely be closing this issue in the future.

[richardb64]

I'm not sure this is really a workaround. Determining an appropriate SDDL string is something a typical end user will have little hope of achieving. I suppose in some cases the maintainers of the individual filesystems might be willing to add a suitable SDDL by default (if they don't mind introducing platform-specific code). In either case, though, if I'm understanding the new feature correctly, the end result would be something that masks the underlying permissions, rather than trying to reflect them as closely as possible in "Windows speak". If the recommended SDDL ("D:P(A;;FA;;;)") is "combine[d] with the owner/group information from the -o uid=UID,gid=GID options", does that mean the handling of the "uid=gid" case will still need to be changed anyway to avoid the original problem, ie. that WinFsp prevents access that should be possible?

"Linking with a Microsoft account" is something that Microsoft appears to be pushing very hard in Windows 10, so I think WinFsp needs to support the "uid=gid" (or "TokenGroups doesn't include the TokenPrimaryGroup") case directly, without any workarounds. Users expect to be able to run "sshfs host:/path /local/path" (maybe with -oidmap=user) and for it to Just Work.

The effective permissions that are actually enforced are always the stricter of the Windows permissions and the underlying filesystem permissions, so I don't think there would ever be a security problem in practice, if WinFsp were to err on the side of being relaxed (eg. by ORing the user and group bits, instead of ANDing them). What's the scenario you feel might be problematic?

[billziss-gh]

@richardb64

This issue happens for people with Microsoft accounts when the option -o uid=-1,gid=-1 is specified (either implicitly by the file system or explicitly by the user). If only -o uid=-1 is specified, then things work. If -o uid=-1,gid=ANY (with ANY != -1) is specified then things work. If -o uid=-1,gid=-1,umask=0770 is specified then things work.

Given this I think it is reasonable to say that if -o uid=-1,gid=-1 does not work correctly for some people, then this command line should be changed for these people rather than modifying security in a backwards-incompatible manner for everyone.

If the recommended SDDL ("D:P(A;;FA;;;)") is "combine[d] with the owner/group information from the -o uid=UID,gid=GID options", does that mean the handling of the "uid=gid" case will still need to be changed anyway to avoid the original problem, ie. that WinFsp prevents access that should be possible?

This is not the case. The -o FileSecurity=SDDL option completely circumvents the whole POSIX permissions to ACL mapping (but still retains the UID/GID to SID mapping). So the problem discussed in this issue would not be relevant when using this option.

[billziss-gh]

I have given additional thought to this problem and decided to address it as follows:

• The default behavior of WinFsp-FUSE remains the same when UID == GID with respect to computation of permissions (i.e. the most restrictive permissions are computed for both owner and group when they are the same).

• A new registry setting named DistinctPermsForSameOwnerGroup has been added, which can be used to change this default behavior of WinFsp-FUSE.

• The DistinctPermsForSameOwnerGroup setting is a REG_DWORD value under HKLM\Software\WinFsp (or HKLM\SOFTWARE\WOW6432Node\WinFsp on Win64).

• When the setting is 0 (the default), WinFsp-FUSE matches the existing behavior.

• When the setting is 1, WinFsp-FUSE computes distint permissions for the UID and GID even when UID == GID. This addresses the main issue discussed in this thread.

• This maintains backwards compatibility, but gives the ability to system administrators to change WinFsp-FUSE behavior. Going forward we can also consider making 1 the default.

Commit 50892bf addresses this issue.

[richardb64]

This sounds like another good workaround. Unfortunately, it is still only a workaround (unless it becomes the default), which the user would need to research to know about.

"Linking with a Microsoft account" is going to be widespread (maybe MS publishes some statistics?) precisely in the same cases where the end user is their own sysadmin, and may be less skilled in identifying either the problem or the workaround. So I still think that WinFsp-FUSE needs to work well in that environment out of the box.

What is the actual security issue which would be introduced by allowing WinFsp to present slightly more relaxed permissions than the underlying FUSE filesystem enforces? In fact, what is the likelihood of seeing UID==GID in the wild other than in the "linked with MS account" case?

[billziss-gh]

As I have said in previous messages backwards compatibility is important for the WinFsp project. The latest change gives us a path forward and adds the possibility to eventually change the default behavior while maintaining backwards compatibility for those who need it.

I understand that you want the default behavior changed and perhaps this will happen in the future.

[billziss-gh]

FYI, the default behavior is changing in WinFsp 2022+ARM64 (currently in Beta).

WinFsp-FUSE will now be computing distinct permissions for the UID and GID even when UID == GID. The default value of the registry setting DistinctPermsForSameOwnerGroup will be 1 when not explicitly set.