Should we hide xattr "Security.NTACL" from EA API calls?

[lundman]

OpenZFS stores the Windows produced Security blobs in xattrs, as it is a convenience place to store them. So far I haven't "hidden" them when you iterate EAs on objects, NTFS wouldn't show them, since they are not EAs, but Security Descriptors.

I haven't done that since I can not make any particular guarantees towards Windows Security. You might set a Directory to only be readable by $user, but mount the pool under Unix system, and the NTACL is irrelevant. To OpenZFS, the Unix permissions is what matters. Obviously, using the pool under another OS is a lot more work than "deleting an EA as a regular user" to get around it.

ChatGPT swings in the other direction with:

yes—mask it. Treat your _NTACL as an internal storage detail, not a user-visible EA.

Why hide Security.NTACL from EA APIs?

Windows semantics: SDs live in $Secure and are managed via IRP_MJ_QUERY_SECURITY / IRP_MJ_SET_SECURITY, not EAs. Letting apps see/modify an SD via EAs bypasses owner/caller evaluation (SeAssignSecurityEx), inheritance, canonicalization, auditing, and could create malformed SDs.

Correctness & safety: If someone tweaks _NTACL with NtSetEaFile, you might persist an SD that doesn’t match what SeAssignSecurityEx would have produced (wrong owner/DACL order/flags), leading to subtle access bugs or the “Recycle Bin is corrupted”-style issues you just fixed.

Compatibility noise: Exposing _NTACL breaks tools/tests that assume “NTFS-like” EA size/ordering. Masking it makes FileEaInformation.EaSize and enumeration behave like NTFS (or at least not surprising).

No real downside: Anyone who wants to muck with ACLs can (and should) use SetSecurityInfo/SetNamedSecurityInfo. On Unix, yes, they can mount and edit the xattr—that’s fine; but on Windows, keep the Windows contract.

So let's throw the question out there to people who perhaps intend to use NTACL to control access to their data.. strong opinion either way?

[sskras]

(I don't use NT ACLs yet, so this is just my 2 cents)

OpenZFS stores the Windows produced Security blobs in xattrs, as it is a convenience place to store them.

Cool documentation tip. (1) Is the mapping format described somewhere?

Also* (2) does the mapping take into account the original owner and owning group IDs and permissions?

So far I haven't "hidden" them when you iterate EAs on objects, NTFS wouldn't show them, since they are not EAs, but Security Descriptors.

I haven't done that since I can not make any particular guarantees towards Windows Security. You might set a Directory to only be readable by $user, but mount the pool under Unix system, and the NTACL is irrelevant. To OpenZFS, the Unix permissions is what matters.

On *nix yes, OpenZFS driver should care about reporting the Unix permissions.
But on Windows the driver should do so about reporting the Security Descriptors. No? At those SDs set by the Windows itself.

Obviously, using the pool under another OS is a lot more work than "deleting an EA as a regular user" to get around it.

Ummm, it might be that my English is too bad, but ... I don't get this part. Could you rephrase it in more specific way, please?

ChatGPT swings in the other direction with:

yes—mask it. Treat your _NTACL as an internal storage detail, not a user-visible EA.
Why hide Security.NTACL from EA APIs?
Windows semantics: SDs live in $Secure and are managed via IRP_MJ_QUERY_SECURITY / IRP_MJ_SET_SECURITY, not EAs. Letting apps see/modify an SD via EAs bypasses owner/caller evaluation (SeAssignSecurityEx), inheritance, canonicalization, auditing, and could create malformed SDs.
Correctness & safety: If someone tweaks _NTACL with NtSetEaFile, you might persist an SD that doesn’t match what SeAssignSecurityEx would have produced (wrong owner/DACL order/flags), leading to subtle access bugs or the “Recycle Bin is corrupted”-style issues you just fixed.
Compatibility noise: Exposing _NTACL breaks tools/tests that assume “NTFS-like” EA size/ordering. Masking it makes FileEaInformation.EaSize and enumeration behave like NTFS (or at least not surprising).

Is this even true? IOW, could something really break due to particular EA size/ordering, really?

No real downside: Anyone who wants to muck with ACLs can (and should) use SetSecurityInfo/SetNamedSecurityInfo. On Unix, yes, they can mount and edit the xattr—that’s fine; but on Windows, keep the Windows contract.

So let's throw the question out there to people who perhaps intend to use NTACL to control access to their data.. strong opinion either way?

Here I agree with ChatGPT. I would just try to filter out these specifics EA conditionally – only when mimicking NTFS.

[sskras]

[*] Though not directly related to OpenZFS for Windows, eg. Cygwin needs the opposite mapping, and seemingly invokes some magic via non-canonical SDescriptors. Eg: How does chmod +x work in cygwin?

It would be nice if the Cygwin-like layers could have a way to reconstruct the original owner + group + the permission triplet.

[guenther-alka]

ZFS is a Unix filesystem with File owner a uid/gid, with rwx permissions and optionally Posix (NFSv4) ACL

OpenZFS stores the Windows produced Security blobs in xattrs, as it is a convenience place to store them.```

Does this mean that there is no problem moving a pool from/to Free-BSD/Linux/OSX/Windows
and each platform sees its "native" file owner and security/ACL settings or is there a mapping/translation on Windows?

[lundman]

They are relatively disconnected. I do not peek inside the Windows blob at all, just pass it around. But I do need to give a uid,gid when creating something, so that is taken from the SIDs, last few digits, so it stays consistent across boots/mounts.
So you can tell Windows to only allow UserSID access to a folder, but mount pool under Unix and it has no such knowledge.