Did some experiments today to see how mode bits are stored by the Windows NFS server in the RichACL (CIFS or NFS ACL). mounted nfsv4.1 to Windows from Linux then created a bunch of files and did chmod of various combinations of 07777 bits (including sticky, setuid etc.) Windows NFS server is storing the user owner bits with SID S-1-5-88-1 and using SID S-15-88-2 for group owner and S-1-5-88-4 for the ACE for "other" (this is easy to spot over CIFS/SMB3 etc because user owner and group owner map to these SIDs in the security descriptor returned over the wire). As expected, for each of the 3 ACEs, it is setting "GENERIC_READ" in the ACE for '4' (read) and GENERIC_WRITE for '2' (write) and GENERIC_EXECUTE for '1' (execute). What is puzzling is where it stores the setuid and sticky bits (bits 07000) because they are not visible in the CIFS/NTFS ACL. Interesting that Windows's ACL management tool "cacls" doesn't display the human readable names of the three special SIDs (even when run locally on NTFS) although does display the ACE associated with the sid with its raw SID. Trying it on a different server which also handles both NFS and CIFS/SMB3, the Mac, was also interesting. Strangely enough the Mac client didn't seem to recognize these ACEs (I thought they did) - and ls -l in Mac's bash always shows mode of 0700 In addition the Mac server doesn't seem to support Query Security descriptor from cifs (Linux) or SMB2.1 (Windows 8.1) so I couldn't run "cacls" on the Windows mount to Mac server to view how the Mac handles chmod of the various permission bits (what it does to emulate them in the ACL). -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
