samba - Mar 2022 - Remove all Windows ACL's from files/folders

On Tue, Mar 29, 2022 at 8:17 AM Patrick Goetz via samba <
samba at lists.samba.org> wrote:
>
>
> -SNIP-
> >
> > In all the testing I've done, setting the POSIX perms (via
> setfacl/chown/chmod) doesn't do anything to reset or modify the
"Windows"
> ACL listing.
> > -This probably is because I have: acl_xattr:ignore system acls = yes
> (But I only have this set so I can tweak permissions from Windows at all!
> Without it, any permissions mods fail as though I don't have the
correct
> privs, even though I'm doing them as Administrator.)
>
> Just one comment on this for now, as I'm in the middle of a time
> sensitive deployment:
>
> I use the same [global] defaults for all shares:
>
>     vfs objects = acl_xattr
>     map acl inherit = yes
>     store dos attributes = yes  # (Yes, I know this is now the default)
>
> and generally have no problems changing permissions from Windows; either
> as administrator or (I need to double check this) as any other user with
> Full Privileges.  If you have to set acl_xattr:ignore system acls = yes
> in order to edit privileges from Windows, I suspect something else must
> be wrong.
>
> Have you tried adding this to the [global] section of /etc/samba/smb.conf?
>
>     min domain uid = 0
>
>min domain uid = 0
Yes, I do have this.
>If you have to set acl_xattr:ignore system acls = yes in order to edit
privileges from Windows, I suspect something else must be wrong.

And yes, several people have noted that it's "odd" for
"acl_xattr:ignore
system acls = yes" to be the only way to edit Windows perms from an admin
level equiv - but Rowland noticed something similar that he thought was a
bug, and my testing seems to also show something very similar to what he
experienced. (But the couple of threads I've posted since hasn't
provoked
any direct response from RP or Louis that really addresses any of this. Not
that I'm upset about that, but just that the two best people on the
list, in practical terms, to answer these questions, IMO, haven't really
weighed in. :)

But I need to do one final set of tests - and part of the need to be sure
the Windows ACL's were fully reset was to be sure that some odd
"stuck" ACL
wasn't part of the problem. (I don't think that's the case, but
I've been
banging my head against the wall trying to ensure that the Windows ACL's
were fully reset before doing more testing, since unless I started clean,
it was impossible to interpret any results in any meaningful way. I think
I've got that now, so we'll see.)

So, yes, I don't think acl_xattr:ignore system acls = yes *should* be
required, but every time I've tinkered, I can't do anything without it
being set.

I'll report back shortly with the what I find with a clean slate of
ACL's
to start with.

-Greg

>
>
> >
> > (And tweaking acl_xattr:default acl style = Windows/posix didn't
make
> any difference either.)
> >
> > With a few new ideas and some re-reading of the docs, I tried the
> following and it DOES remove the Windows ACL's.
> >
> > cd into the directory you want to mod.
> > setfattr -x security.NTACL ./
> >
> > But there's no "recursive" switch for setfattr, so
there's no easy way
> to force it to process all files and directories. You can only remove a
> single ACL at a time. I suppose you might be able to craft something with
> find, but if you've got a large tree, it's not going to be speedy,
and I
> suspect it's going to generate a ton of IO.
> >
> > But since I really only want to mod the "root" share folder
and then
> fully reset the permissions and then push them down to all child objects,
> this may well work for my situation.
> >
> > And when I do this the permission changes are immediately visible in
> Windows file explorer.
> >
> > Someone should clearly document this in the Wiki.
> > (I suppose if I get enough energy I could do it, but this has been a
> pretty frustrating journey, so motivation is in short supply.)
> >
> > -Greg
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>

Sorry for the long post;
The gist is:

1) I set permissions in the Windows UI, and it appears to be successful.
2) I then attempt to access a share, from a domain joined Windows PC, using
the user (and group) I've assigned "full control" to.
3) It Fails.
4) So, I check the Samba logs - sure enough it shows that user attempting
to access that share.
5) I check to be sure the UID matches the UID of the user. It does.
6) I check the GID and it also matches.
7) I check the NTACL perms that Samba thinks are set, and look (as best I
can understand) the SDDL output.
8) And the SDDL output doesn't even remotely match the permissions I set in
Windows.

And I have no idea where to look next to figure out why.

Following is the "show my work" section. :)
---

So, I'm only able to set permissions (as Administrator) with
"acl_xattr:ignore system acls = yes" set.
(Which is "wrong" but lets just go with it. You'll see where
I'm going in a
minute.)

So, I set the permissions on a share to the following. (From the Windows
file explorer)
Allow root: full control
Allow SYSTEM: full control
Allow Domain Admins: full control
Allow: Domain Users: full control
Allow ad\gs: full control

I'm testing with a test user, AD\GS.
GS is a member of domain users, which should grant access, but doesn't.
So, I add the user explicitly, which also fails to grant access.

So, check the Samba logs.
---
2022/03/29 10:23:54.736440,  0]
../../source3/smbd/service.c:168(chdir_current_service)
  chdir_current_service:
vfs_ChDir(/abc-zfs-01/ad-shared-folders/shared-files) failed: Permission
denied. Current token: uid=11608, gid=10513, 7 groups: 11608 10513 11129
3003 3004 3006 3001
---
# wbinfo -i "ad\gs"
AD\gs:*:11608:10513:gs:/home/AD/gs:/bin/false
---

So the UID in the Samba log matches the user I expect.
That's good.
At least the user attempting access matches the user I've set permissions
for,

---
Incidentally, the group matches too;
wbinfo -i "ad\domain users"
AD\domain users:*:10513:10513::/home/AD/domain users:/bin/false
---

So, now lets see what Samba thinks the permissions are on that
share/directory.

---
getfattr -n security.NTACL /abc-zfs-01/ad-shared-folders/shared-files/
samba-tool ntacl get /abc-zfs-01/ad-shared-folders/shared-files/ --as-sddl

And I get:
O:S-1-22-1-0G:DAD:(A;;0x001f01ff;;;S-1-22-1-0)(A;;0x001f01ff;;;DA)(A;;0x001200a9;;;WD)(A;OICIIO;0x001f01ff;;;CO)(A;OICIIO;0x001200a9;;;CG)(A;OICIIO;0x001200a9;;;WD)

However, I'm a bit lost decoding that - but it really doesn't look like
I'd
expect.
It looks to have a couple of "everyone" permissions - which isn't
in the
Windows UI.
Also, there's a "Creator Owner" and "Creator Group"
which aren't in the ACL
I've set in Windows. And I don't see the "Domain Users" or the
explicit
User assignment in there.

(Rowland, I'd be happy for a better decode, if you can - but that's what
I
think I see.)

So that would explain a lot - the permissions that Samba thinks is set on
the share/folder don't match, at all, the permissions I set from the
Windows file explorer UI.

Can someone tell me where to look next to figure out why?