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.