[Samba] Windows ACLs and Replication
Steve Tice
stic6021 at yahoo.com
Thu Feb 25 21:54:49 UTC 2016
I work with a product that's similar to a NAS. It utilizes CentOS 6 and Samba v4.0.0-64.el6.rc4 to serve CIFS clients. The product provides "full Windows ACL support" via the acl_xattr module. The underlying file system, a FUSE implementation, provides full support for extended attributes. That much of it works remarkably well.
The product supports an option to replicate shares from a "source" to a "target" instance. The replication software copies directories, files and metadata. Among the metadata copied are the extended attributes. From the perspective of the product, replication works remarkably well. From the perspective of a CIFS client, not so much. I'll elaborate.
In many cases, from the perspective of a CIFS client, the ACL on a given directory or file will be identical on the source and target. In some cases, the ACLs are different. I've observed at least 3 classes of differences:
1. The ACL on the source shows all the expected group and user names, while the ACL on the target shows (some) different group and user names. The number of ACEs, and their content, is the same on source and target. I think this is because the mapping from SID to GID/UID is being performed by independent instances of winbindd (one each on source and target). If you use the --numeric output of smbcacls to compare the ACLs, they are identical. This class of difference is not a big problem for us.
2. The number of ACEs differs between source and target ACLs. For example, smbcacls lists 6 ACEs on the source and 7 ACEs on the target. There is nothing familiar or logical about the extra ACE. This class of difference is a big problem for us.
3. The permissions represented by a given ACE differ between source and target ACLs. For example, smbcacls reports that S-1-1-0 has permissions bits 0x001f01bf on the source and 0x001f01ff on the target. This class of difference is a big problem for us.
Because of classes 2 and 3, I expected to find the extended attribute values differed between source and target. However, the binary data in the extended attributes (security.NTACL, system.posix_acl_access, system.posix_acl_default, user.DOSATTRIB) is identical between source and target. Earlier, I said "from the perspective of the product, replication works remarkably well", and this is what I meant (accurate replication of extended attributes).
Finally, here are my questions:
Q1: Is it possible my observations are correct? In other words, is it possible for a given collection of extended attribute values (as stored on the Samba server) to "produce" varying ACLs as transmitted to CIFS clients?
Q2: Assuming an ACL is "produced" by more than the values in the extended attributes, what are the other factors influencing what a CIFS client sees?
Q3: Is there a practical way to synchronize the source and target servers so they "produce" identical ACLs?
Thanks for reading,Steve Tice
More information about the samba
mailing list