[Samba] POSIX ACLs vs. EA security.NTACLs

[Robert W. Smith]

This might be more inclusive if I said, Linux Permissions vs POSIX ACLs
vs vfs_xattr.

I have recently begun to discover the power and flexibility of using
POSIX ACLs (by mounting my EXT3/4 filesystems with the acl option). This
solved alot of security permissions issues between Samba and Linux
groups of users. As I have delved into this deeper and begun using the
VFS object, vfs_xattr, things again began to get a bit more complicated,
or at least it exposed that I do not understand the relationship between
these three.

Here is a typical share that is used by three classes of users (see
below) (with NFS, the directory):

[Shared]
        comment = Public Share on %h
        path = /home/shared
        valid users = +domadmins, +domusers, +domguests
        write list = +domadmins, +domusers
        force group = domusers
        inherit permissions = yes
        inherit acls = yes
        map acl inherit = yes
        acl group control = yes
        ea support = yes
        vfs object = acl_xattr recycle
        store dos attributes = yes
        map archive = no
        map hidden = no
        map system = no
        map readonly = no

The three classes of users are:

1) Linux only users who belong to a Linux-only group called 'users' --
this is actually the trivial case as all my servers are Samba servers
and NFS servers
2) Linux&Windows users--these users (like myself) use both Linux (NFS)
and Windows (Samba)--they belong to the Linux group 'users' and
'domusers' which is 'DOMAIN\Domain Users' in Windows
3) Windows only users who only belong to the Linux 'domusers' group, or
in Windows, 'DOMAIN\Domain Users' group

I'm using the latest, greatest Fedora (FC14), Samba (3.5.6), NFS  and
LDAP (2.4.23) code--but not Windoze ;-)

They all store and access files in the above share, [Shared]. For Linux
users they use NFS and as Windows users they use Samba. As I have added
the vfs object, acl_xattr, I have realized that this object uses the
extended attribute, security.NTACL, to store the actual Windows ACLs,
which  is different than the POSIX ACLs. I have several questions which
I will just enumerate without being too verbose:

1) Does Samba maintain the consistency between all of the stored NTFS
attributes and POSIX ACLs when using vfs_xattr?

2) When might the POSIX ACL not be in sync with the vfs_xattr EA stored
in security.NTACL when using Samba?

3) If both POSIX ACL and security.NTACL exist on a file/directory, which
does smbcacls show? What does Win* Properties-->Security show? What does
smbclient show?

4) With 'inherit acls = yes' what does 'default acl' imply? All ACLs on
the file/directory or just those preceded with the tag 'default'?

5) For the astute reader, since this is a Samba share, I force the group
to be 'domusers' (DOMAIN\Domain Users in Win) for new files/directories.
Will this always be the Linux permission group? Will this overwrite the
Linux group 'users' of existing files or new files where permissions and
ACLs are inherited?

5a) And let me not forget the case where I have set the 'setgid' bit on
directories. Should I turn the setgid bit off with this configuration?

6) I want to always ensure both the Linux only group 'users' and the
'domusers' (which include both Linux and Windows users and Win only
users) are enabled on all files/directories on this share. Hey, I'll
give my silver dollar to the person who can come up with a configuration
that will solve this with both NFS and Samba!

7) Currently, if a users comes to me and says, 'I need the lawyer to
have access to file XYZ', I would grant the POSIX ACL using the Linux
CLI with, # setfacl -m g:mud-suckers:rw, without regard to the users OS
platform. With vfs_xattr, do I now need to somehow 'sync' the POSIX ACL
with the security.NTACL EA? If yes, how?

8) Should I forgo the linux-only group 'users' and merge it (the users)
with the group 'domusers' (Win DOMAIN\Domain Users)? Previously, I
thought that I had a justified reason for keeping them separate but now
with the advances in security mechanisms I am not sure of my reason
anymore. Any one have opinion on this? (I'm sure you do :)

I may be a bit behind the curve in advanced security but all I can say
is, 'Wow, this is all great stuff--I just wish we had a single, unified
vision'. If we do, it will all be the result of the Samba Team!

Bob
A lone(ly)  * admin
--bs