samba - Apr 2018 - Is it possible to clone an NT ACL from one file or dir to a totally different file or dir ?

Can I use a command like this to clone an NT ACL?

getfattr -n security.NTACL templateFile | sed -e 
's/templateFile/realFile/' | sudo setfattr --restore=-

I can see that the attribute gets copied over but when I view the ACL in 
Windows security tab it's not the same ACL, it's much bigger and 
includes all kinds of default-like stuff. I'm trying to find a way to 
update permissions on a mass amount of files without using the existing 
Windows/Samba tools which take days to complete on large datasets.

Right now, I have this process, but it's not working and I don't 
understand why.

1) Setup template example file or directory with the desired permission 
structure (call it templateFile here)

2) Create or use an existing destination/target file or directory (call 
it realFile here)

3) Remove all existing perms on realFile:

setfacl -b realFile

setfattr -x user.DOSATTRIB realFile

sudo setfattr -x security.NTACL realFile

4) Clone the extended ACL:

getfacl templateFile | sudo setfacl -bnM - realFile

5) Clone the DOS attributes

getfattr -d templateFile | sed -e 's/templateFile\/realFile/' | setfattr
--restore=-

6) Clone the NTACL

getfattr -n security.NTACL templateFile | sed -e 
's/templateFile/realFile/' | sudo setfattr --restore=-


By default, step 4 takes forever to run on large datasets because it 
uses named entities. My ultimate plan was to use the numeric user/group 
id's in that step instead of named ones so the Winbind cost is not 
incurred. Seems for the whole process, the calls to Winbind to resolve 
the named entity to it's numeric ID are the reason for the slowdown. 
That's why, even when using the normal Windows security tab or 
samba-tool, it takes days to update large datasets. I'm exploring 
options around that issue.

On 03/24/2018 08:20 PM, Ken McDonald via samba wrote:
> Can I use a command like this to clone an NT ACL?
>
> getfattr -n security.NTACL templateFile | sed -e 
> 's/templateFile/realFile/' | sudo setfattr --restore=-
>
> I can see that the attribute gets copied over but when I view the ACL 
> in Windows security tab it's not the same ACL, it's much bigger and
> includes all kinds of default-like stuff. I'm trying to find a way to 
> update permissions on a mass amount of files without using the 
> existing Windows/Samba tools which take days to complete on large 
> datasets.
>
> Right now, I have this process, but it's not working and I don't 
> understand why.
>
> 1) Setup template example file or directory with the desired 
> permission structure (call it templateFile here)
>
> 2) Create or use an existing destination/target file or directory 
> (call it realFile here)
>
> 3) Remove all existing perms on realFile:
>
> setfacl -b realFile
>
> setfattr -x user.DOSATTRIB realFile
>
> sudo setfattr -x security.NTACL realFile
>
> 4) Clone the extended ACL:
>
> getfacl templateFile | sudo setfacl -bnM - realFile
>
> 5) Clone the DOS attributes
>
> getfattr -d templateFile | sed -e 's/templateFile\/realFile/' | 
> setfattr --restore=-
That had a typo when I shortened it to an example form. Should have been
5) Clone the DOS attributes
getfattr -d templateFile | sed -e 's/templateFile/realFile/' | setfattr 
--restore=-
>
> 6) Clone the NTACL
>
> getfattr -n security.NTACL templateFile | sed -e 
> 's/templateFile/realFile/' | sudo setfattr --restore=-
>
>
> By default, step 4 takes forever to run on large datasets because it 
> uses named entities. My ultimate plan was to use the numeric 
> user/group id's in that step instead of named ones so the Winbind cost 
> is not incurred. Seems for the whole process, the calls to Winbind to 
> resolve the named entity to it's numeric ID are the reason for the 
> slowdown. That's why, even when using the normal Windows security tab 
> or samba-tool, it takes days to update large datasets. I'm exploring 
> options around that issue.
>
>

On Sat, 2018-03-24 at 20:38 -0400, Ken McDonald via samba
wrote:
> 
> > By default, step 4 takes forever to run on large datasets because it 
> > uses named entities. My ultimate plan was to use the numeric 
> > user/group id's in that step instead of named ones so the Winbind
cost
> > is not incurred. Seems for the whole process, the calls to Winbind to 
> > resolve the named entity to it's numeric ID are the reason for the
> > slowdown. That's why, even when using the normal Windows security
tab
> > or samba-tool, it takes days to update large datasets. I'm
exploring
> > options around that issue.
If this is on the AD DC, then I fixed part of the slowness here a
couple of week ago with 

commit d418d0ca33afb41a793a2fff19ca68871aa5e9ef
Author: Andrew Bartlett <abartlet at samba.org>
Date:   Wed Mar 21 20:43:10 2018 +1300

    winbindd: Add a cache of the samr and lsa handles for the passdb
domain

Otherwise, I'm not sure folks have looked into this terribly much, you
are already working at a pretty low level.

I hope this helps a little.

Andrew Bartlett
-- 
Andrew Bartlett
https://samba.org/~abartlet/
Authentication Developer, Samba Team         https://samba.org
Samba Development and Support, Catalyst IT   
https://catalyst.net.nz/services/samba