[Samba] SMB Windows ACL functionality

Bailey Allison ballison at 45drives.com
Tue Jul 12 22:10:51 UTC 2022


Hi All,

First of all, thank you very much everyone for the replies the insight is
much appreciated!

Rowland, per your:

> I carried out the same tests on another machine (this time using
> 'rid'), but this computer did not map Administrator to root with a
> User.map
> 
> Everything else was the same.
> Logged into Win10 as Administrator, I couldn't change anything, I
> expected this.
> 
> Logged in as myself, I could alter the permissions on the share that
> didn't have 'acl_xattr:ignore system acls = yes' set, but on the other,
> I got:
> 
> An error occured while applying security information to
> \\mintclient\acltest2
> 
> Failed to enumerate objects in the container. Access is denied.

I can verify I am seeing the same behaviour, without the 'acl_xattr: ignore
system acls = yes' set I can modify permissions from the root of the share
and within.

I can't modify at the root of the share using myself (DOMAIN\bailey) with
'acl_xattr: ignore system acls = yes' set, but if I am to create a
file/folder within the share using 'acl_xattr:ignore system acls = yes' set
I can then modify the permissions on that folder/file as I please, I suspect
due to that created folder having full control for my user assigned when
creating it, whereas it seems the root of the share my "DOMAIN/Domain
Admins" group only has read write execute access not full control despite
permissions being set to 0770. 

These permissions then do not present as extended ACLs on the Ubuntu server
checking with getfacl on the directory, however they do show up when
querying with getfattr which I assume is due to:

> so the module can implement the permission  evaluation in userspace based
on the contents of the NT ACL stored in an xattr, without interference of
filesystem permissions.

Which makes sense as we're reading the permissions in userspace from the NT
ACL as you have mentioned.

In addition, per the manpage for acl_xattr:

"acl_xattr:ignore system acls = [yes|no]

When set to yes, a best effort mapping from/to the POSIX ACL layer will not
be done by this module. The default is no, which means that Samba keeps
setting and evaluating both the system ACLs and the NT ACLs. This is better
if you need your system ACLs be set for local or NFS file access, too. If
you only access the data via Samba you might set this to yes to achieve
better NT ACL compatibility."

Which makes sense as this is the behaviour we are seeing.

I guess the curious thing at this point is that both methods do appear to
work just in separate ways? As a quick tl:dr would it be fair to say that:

With 'acl_xattr: ignore system acls = yes' set, the Windows ACLs are applied
in userspace and read from that. Downside is this allows anyone who has
local access to the filesystem full control as everything is written with
open access.

With 'acl_xattr: ignore system acls = no' set, the Windows ACLs are applied
directly to the actual filesystem/kernel similar to if we were to manually
set permissions with setfacl, in addition making the samba server aware of
the ACL changes directly as well as Windows clients.

Both options do allow setting and modifying of Windows ACLs but have
different results on the filesystem we're sharing out from the samba server.

So I guess perhaps it's almost up to user preference which method to use?
Obviously as mentioned before there's some caveats to using the 'acl_xattr:
ignore system acls = yes' options.

Again, really appreciate the insight on this from everyone as I feel I've
gotten a much better understanding of what is going on.

Bailey

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba




More information about the samba mailing list