[Ms-nfs41-client-devel] Windows Server NFS, getfact not working on NFS

[Sam Edge]

On 29/10/2024 15:47, Corinna Vinschen via Cygwin wrote:
> On Oct 29 15:08, Sam Edge via Cygwin wrote:
>> On 29/10/2024 14:38, Corinna Vinschen via Cygwin wrote:
>>> On Oct 29 13:56, Martin Wege via Cygwin wrote:
>>>> No, FILE_PERSISTENT_ACLS is not in that output.
>>>>
>>>> Reading https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getvolumeinformationa
>>>> it means that the Windows NFSv4.1 server does not support ACLs?
>>>
>>> https://learn.microsoft.com/en-us/answers/questions/1132611/windows-nfs-server-acls
>>>
>> To the point as always. :-)
>>
>> However the answer in that link raises more questions.
>>
>> a) Does that mean NFS-served ACLs /are/ supported by Cygwin if the "stored
>> in GPFS as POSIX ACLs" caveat applies?
> 
> If the external GPFS filesystem sets the FILE_PERSISTENT_ACLS flag when
> communicating with a Windows client, then yes.  Otherwise no.
> 
>> I've just been reviewing the Cygwin user guide. The following took my eye.
>>
>>> noacl - Cygwin ignores filesystem ACLs and only fakes a subset of
>>> permission bits based on the DOS readonly attribute. This
>>> behaviour is the default on FAT and FAT32. The flag is
>>> ignored on NFS filesystems.
>>
>> b) Does this mean ACLs are ALWAYS support on NFS or NEVER supported?
> 
> The user guide contains this:
> 
> https://cygwin.com/cygwin-ug-net/using-filemodes.html
> 
> NFSv3 == POSIX file permission bits as in st_mode.
> 
> As I wrote months ago, the NFSv4 driver should not use "NFS" as
> filesystem name, but something like "NFS4". This way, the two
> filesystems can be distinguished and handled separately.  Given that
> Windows doesn't care for the name, but Cygwin does, this opens up the
> chance to add special handling for the NFSv4 driver to Cygwin.
> 
> The first and foremost effect, without *any* changes in Cygwin
> necessary, would be that Cygwin handles the NFSv4 driver just like
> any other non-NFS driver:
> 
> - Flags like FILE_PERSISTENT_ACLS would actually be utilized.
> 
> - stat info would be fetched using
>    NtQueryInformationFile(FileAllInformation) rather than via the
>    NFS-specific NtQueryEaFile("NfsV3Attributes").
> 
> - Along the same lines, symlinks won't be recognized by the
>    NfsV3Attributes stat info, but by the Windows default way
>    of checking for a reparse point of type IO_REPARSE_TAG_SYMLINK
>    (or IO_REPARSE_TAG_LX_SYMLINK if NFSv4 supports it).
> 
> And repeating myself, maybe in other words, but Cygwin doesn't do
> anything magical.  It's just a user-space DLL relying on the same info
> the Windows OS gets.  It's just a matter of how to use that info.
> 
> So if you get the info through to Windows, there's always a way to get
> it through to Cygwin either.
> 
> 
> Corinna
> 

Hi.

My apologies if I've annoyed you. It was certainly not my intention.

I understand that Cygwin can only use the underlying APIs made available 
to it and I'm not trying to suggest that anything should or should not 
be supported either now or in the future. I also appreciate that NFSv4 
has ACLs baked in whereas they are (sometimes) bolted on using OOB RPC 
in earlier iterations of NFS, same as file locking I believe.

But boil it back down to Martin's original question.

If he can see/use ACLs when mounting an NFS share from a Windows server 
using a Linux client, should it be /possible/ for him to do so for the 
same share from a Cygwin+SFU+Windows client?

Can anyone give him a definitive answer? A simple yes or no at this point?

If 'yes', given he claims he's getting 'no', what might be blocking him?

I have no stake in this. I don't use Windows NFS servers.

-- 
Sam Edge
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x8AC2CEBF54528E30.asc
Type: application/pgp-keys
Size: 648 bytes
Desc: OpenPGP public key
URL: <https://cygwin.com/pipermail/cygwin/attachments/20241029/adb62dfc/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://cygwin.com/pipermail/cygwin/attachments/20241029/adb62dfc/attachment-0001.sig>