virtio-fs with a win10 QEMU guest and WinFsp

1,672 views
Skip to first unread message

Marcello Pietrobon

unread,
Feb 2, 2021, 2:40:05 PM2/2/21
to WinFsp
As probably well known virtio-fs on a Win10(20H2) Windows guest is unusable for some users.

Yet the problem seems to disappear if we restart the Virtio FS Service
It's not completely clear to me if it is a virtio-fs problem or of WinFps.

Here's the analysis.

I'm using virt-manager as described in
The problem is similarly described in different threads:
a. Replacing a file on the drive, windows wants admin credentials...?
Essentially  you can create/delete files or directories on a drived mapped through virtio-fs, but you cannot modify them in any way, where in the case of a directory this means to add any file to it or remove it).
b. User group related permission issues on Windows 10 #204
where StevenDoesStuffs laments a similar, yet not identical, problem.

c. how to use virtiofs in Windows 10 guest? #473
as described by Aetf and mgjadoul and StevenDoesStuffs
and also jakubklos77 (see next point)

d. jakubklos77
where he uses sshfs-Win and WinFSP
Personally the problem I have is exactly identical to the one described at point a.

What all of these have in common? that they all use some form of Fuse

So I went through the code of kvm-guest-drivers-windows-master\viofs\svc\virtiofs.c looking for all the calls of some FspXXX() function and at the end the only ones relevant to the this problem seem to be FspPosixMapWindowsToPosixPath() or FspPosixMapSecurityDescriptorToPermissions()
I couldn't easily continue from there because I tried to force the security permissions similarly to what recently done in the Fuse API with the introduction of FspPosixMergePermissionsToSecurityDescriptor(). It got hard to compile because of a required call to ConvertStringSecurityDescriptorToSecurityDescriptor() as done also in fsp_fuse_sddl_to_security()
Here it comes the interesting point.
If I use from the guest the tools fsptool-x64.exe or Icacls we notice that uid is 0
>"c:\Program Files (x86)\WinFsp\bin\fsptool-x64.exe"  perm z:\test.txt
O:S-1-5-0G:S-1-5-0D:P(A;;0x1f01bf;;;S-1-5-0)(A;;0x1201af;;;S-1-5-0)(A;;0x1200a9;;;WD) (perm=0:0:0775)

>Icacls z:\test.txt
z:\test.txt S-1-5-0:(M,WDAC,WO)
  S-1-5-0:(RX,WD,AD,WA)
  Everyone:(RX)

and if I just restart the Virtio FS Service (C:\Programs\VioFs\w10\amd64\virtiofs.exe), that is I do not even restart the WinFsp.Launcher service ("C:\Program Files (x86)\WinFsp\bin\launcher-x64.exe"), then the problem seems solved.
>"c:\Program Files (x86)\WinFsp\bin\fsptool-x64.exe"  perm z:\test.txt
O:S-1-5-21-2819646085-1004851513-3197712829-1001G:S-1-5-21-2819646085-1004851513-3197712829-513D:P(A;;0x1f01bf;;;S-1-5-21-2819646085-1004851513-3197712829-1001)(A;;0x1201af;;;S-1-5-21-2819646085-1004851513-3197712829-513)(A;;0x1200a9;;;WD) (perm=197609:197121:0775)

>Icacls z:\test.txt
z:\test.txt DESKTOP-MYSELF\myself:(M,WDAC,WO)
  DESKTOP-MYSELF\None:(RX,WD,AD,WA)
  Everyone:(RX)

This is the only output that changes if I run any of the commands described in the post referred at point a. WinFsp\bin\diag.exe included.

Of course I hope this problem will be solved because Samba seem not to work after 2019, and the same is with NFS for different reasons. Or at least I couldn't after trying the entire internet (with my limited experience and understanding).

If you need that I perform some testing I'll be available.
I may try to link this post to the virtio-fs forum if that can help figure out how to resolve this problem.

Thank you.

Bill Zissimopoulos

unread,
Feb 2, 2021, 6:17:41 PM2/2/21
to Marcello Pietrobon, WinFsp

Marcello:

 

I understand that mapping of UNIX security to Windows security is confusing and is causing headaches for many. Below I will briefly explain what the mapping is and why it is necessary. Then I will discuss your output of the fsptool commands. (But please note that I know practically nothing about virtiofs.)

 

 

NEED FOR A MAPPING

 

Files on UNIX have an associated owner and group and a set of Read, Write, eXecute permissions. The owner is encoded as a small integer (e.g. 32-bit number) and is called UID; likewise the group is encoded as another small integer and is called GID. UID's and GID's are in a different namespace, so that even if UID == GID, they actually refer to different security entities. Finally UNIX permissions can be encoded using 9 bits: 3 bits for Read, Write, eXecute for the owner, 3 bits for the group and 3 bits for everyone else.

 

Files on Windows also have an associated owner (and group – although this is less important in the Windows security model) and a set of access permissions. The owner is encoded as a series of numbers called a SID (Security Identifier). Access permissions are encoded as a list of "Allow" or "Deny" entries for individual permissions; this list is called an ACL (Access Control List). Furthermore the Windows permissions are more fine-grained than the ones available on UNIX. (For example, Windows has both a Write and an Append permission, whereas UNIX only has Write).

 

When working with file systems the following problem often arises: a file that is stored on a computer that follows the UNIX security model must be made available to a Windows computer (and vice-versa). Naturally if we want to enforce any kind of security we must somehow map a UNIX UID to a Windows SID and a UNIX permission bitmask to a Windows ACL (and vice-versa).

 

 

NEED FOR A WINFSP MAPPING

 

Whenever Windows open a file in a WinFsp file system, the file system must apply a security check using Windows security rules. For user mode file systems this means passing the file's security descriptor (a binary blob that contains both the file owner SID and its ACL) to the Windows AccessCheck API.

 

So WinFsp interrogates the security descriptor for the file that is about to be opened. However in a FUSE file system there is no operation that returns a Windows security descriptor. Instead FUSE has the getattr operation that returns a "struct stat" that contains the file's UID, GID and MODE. WinFsp now has to translate this UID, GID and MODE to a sensible security descriptor that it can then feed to the AccessCheck API.

 

For this purpose WinFsp uses a mapping that is compatible with SFU ("Services for UNIX") and Cygwin. The assumption is that the FUSE file system will return UID/GID's in the expected namespace. (This may of course mean that the FUSE file system may have to do an additional mapping between the target file system computer's UID/GID and the UID/GID expected by WinFsp, but that is a different identity mapping problem where UID's are mapped to UID's rather than to SID's – WinFsp does not currently provide any assistance with this problem.)

 

 

COMMENTS ON THE FSPTOOL OUTPUT

 

With this background let's discuss the fsptool output you saw:

 

If I use from the guest the tools fsptool-x64.exe or Icacls we notice that uid is 0

                             >"c:\Program Files (x86)\WinFsp\bin\fsptool-x64.exe"  perm z:\test.txt

                             O:S-1-5-0G:S-1-5-0D:P(A;;0x1f01bf;;;S-1-5-0)(A;;0x1201af;;;S-1-5-0)(A;;0x1200a9;;;WD) (perm=0:0:0775)

 

My first response was going to be that the file system returned UID == GID == 0 in its FUSE getattr implementation. But when I actually looked at the virtiofs source code I saw that this file system implements the native WinFsp API. This means that relevant security calls would be in the operations GetSecurityByName and GetSecurity:

 

 

Both of these functions call the WinFsp API FspPosixMapPermissionsToSecurityDescriptor to map UNIX permissions (that they got from their internal API's) to Windows security descriptors. For example, GetSecurity calls (via GetFileInfoInternal) the internal VirtFsFuseRequest to perform a getattr. I bet that the returned VirtFs->LocalUid == VirtFs->LocalGid == 0, but do not ask me why.

 

In any case this seems unrelated to WinFsp. I note that FspPosixMapUidToSid returns the SID S-1-0-65534 when it fails to map (and not S-1-5-0).

 

Bill

--
You received this message because you are subscribed to the Google Groups "WinFsp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to winfsp+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/winfsp/b10d48a8-f336-4af1-bfb8-415e3a65b17fn%40googlegroups.com.

Marcello Pietrobon

unread,
Feb 3, 2021, 9:33:35 AM2/3/21
to WinFsp
Thank you for your explanation which actually has put some lingering doubts I had at rest. This morning my reading of other pages related to this subject was actually finally flowing.

I posted a parallel description on the virtio-fs forum, hoping that this issue will be completely solved.
Reply all
Reply to author
Forward
0 new messages