Questions about Windows SID to Posix uid/gid mapping

[Kai Hambrecht]

Hi Bill,

after reading WinFSP code [1] and cygwin docs [2], I have two questions about the Windows SID to Posix uid/gid mapping mechanism:

1. Let's have a Windows AD user account whose SID starts with "S-1-5-21-2075841214-.....", so we can assume this one to be a regular user account SID (and not any of those "special" or well-known SID's). Mapping of such SID in WinFSP should work according to the logic described in [2]. However when checking the mapping with "fsptool" the resulting uid and gid is "65534", which is defined as "FspUnmappedUid". As far as I understand the WinFSP code here [1], the only case this could happen, is when the machine belongs to a primary domain but the user account does belong to a (different) trusted domain, as this is not yet implemented in WinFSP according to the code comments. Or are there any other cases where a regular user SID would map to the fallback "FspUnmappedUid"?

2. The Windows SID to Posix uid/gid is always calculated by WinFSP on it's own (comparable to cygwin)? But it does not honor any Posix uid/gid attributes from AD, e.g from Windows Services for UNIX or later native attribute support in W2016/2019 AD. So if an organization has assigned arbitrary Posix uid/gid attributes in AD, these will not likely match the Posix uid/gid values WinFSP will calculate?

Thanks,

 Kai.

[1] https://github.com/billziss-gh/winfsp/blob/master/src/shared/ku/posix.c#L436

[2] https://cygwin.com/cygwin-ug-net/ntsec.html

[Bill Zissimopoulos]

Hello, Kal:

 

Apologies for the late response. I have had some personal laptop issues this week and have been unable to respond until just now.

 

Regarding 1: I believe you are correct. My quick reexamination of the relevant code agrees with your assessment.

 

Regarding 2: Yes, WinFsp performs the calculation completely internally. It does not consult the AD.

 

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/84f458b0-13fc-42b0-a9b0-2c9ce7513643%40googlegroups.com.

[Kai Hambrecht]

Hi Bill,

thanks for your reply.

 

Regarding 1: I believe you are correct. My quick reexamination of the relevant code agrees with your assessment.

ok. I have to check the AD membership of user and machine.

 

 

Regarding 2: Yes, WinFsp performs the calculation completely internally. It does not consult the AD.

I was afraid of that. Any chance that WinFSP might support Posix attributes from AD in the future?

To give some background information why this is an issue for me. We're using a cross-platform parallel filesystem client. This client runs on native Linux and via WinFSP on Windows. Both platforms will use AD for user authentication, so a given user "foo" is identical on Windows and Linux. The Linux box will use the Posix attributs of the AD user object to get uid/gid values. But as WinFSP does uid/gid calculation internally, uid/gid do not match. I.e. files written by user "foo" from Windows do not belong to the same user "foo" on Linux (and vice versa) due to different uid/gid. So the cross-platform usage does not work.

Best regards,

 Kai.

[Bill Zissimopoulos]

Regarding 2: Yes, WinFsp performs the calculation completely internally. It does not consult the AD.

 

I was afraid of that. Any chance that WinFSP might support Posix attributes from AD in the future?

 

I think what you are describing is non-trivial, but it certainly sounds like a use case worth supporting it. Please consider opening an issue in the WinFsp GitHub repository to track it.

 

Bill

 

[Kai Hambrecht]

Hi Bill,

I think what you are describing is non-trivial, but it certainly sounds like a use case worth supporting it. Please consider opening an issue in the WinFsp GitHub repository to track it.

done:  https://github.com/billziss-gh/winfsp/issues/306

Thanks,

 Kai.