[Samba] Fwd: Can Samba just store ACL information (without interpreting it) without AD?

Steffen Dettmer steffen.dettmer+samba at gmail.com
Sat Jan 14 19:42:25 UTC 2023


thank you very much for your help and the proposal.
In short: I got Samba ACL working, maybe it already was and resulted
in the problem unable to read just copied files - because of the
updated ACLs.

For the archives / others with a similar problem:
Use xcopy /O to test first, robocopy may have habits that surprise a
unix users (who just wants to implement some rsync -a...).
If xcopy shows errors it could be caused by the fact that ACL are
actually working - the newly set could prevent access to the files
just copied.

Problem is that I don't know who is evaluating this; according to
"when do logfile update with high log level" I think it could be that
windows evaluates that locally (i.e. it sees it has no access so it
does not even try to read the file). Apparently there is nothing Samba
can do about a client-side check...

in more detail:

After spening many hours (no joke) I think I have a different problem;
the ACL are stored (at least with xcopy /O), but then windows loses
its own access. I will write an own question for this.
Interestingly, the domain member client shows the ACE as unknown user
(Windows Explorer Security Properties GUI shows SIDs only), so it
seems it does not "resolve" them; but after copying back to local file
system (with xcopy /O), the human readable user object names appear
(instead of SIDs). So ACL storing itself does work (at least with
acl_tdb, which I switched to for troubleshooting).

I was able to set this option (at least there was no error in log file
when restarting), but I saw no effect.
But I found that the manpage suggests that  "acl_tdb" also exists. Not
in the man page but in the internet I found "vfs objects = acl_tdb"
which eases to test ACL first. There is "samba-tool ntacl get" /
"samba-tool ntacl set", but I'm afraid its complexity is beyond my
intellect. There is"--as-sddl" and reading more about I start to
understand why in Windows there are so many unexpected permission
issues. It is so counter-intuitively overengineered forgetting the
human as target audience I wound why these engineers hate their users
and admins so much that they think this would be suited as an
interface to humans - maybe they thought they would be able to hide it
behind the Explorer GUI and didn't spent efforts, who knows.

As test, I saved SDDL string before, then did xcopy /O. Now from
Windows, I cannot access the files anmore. Now I saved the new SDDL
string, edtited it (Seem even vim has no syntax highlighter for this)
and added the ACE from first string (a straightforward
who would want shell completion support for this simple strings).

With that "merged" ACL, Windows then is able to show and change ACL
information again, although it does not "resolve" SIDs (the GUI shows
them in S-1-1-1 form). When I xcopy/O the file back on a local folder,
then Windows even resolves the SIDs and in the GUI the normal username
information appears in a human readable form.

After this I could use the Windows GUI to remove a bad ACE (which was
overwriting the inherited one with one that affects only the folder,
but not subfolder and files).

Unfortunately I was not able to find why the inherited permission was
replaced by a non-inheritable. Maybe I go though my script, but this
will take another hour...


On Thu, Jan 12, 2023 at 4:31 PM Ralph Boehme <slow at samba.org> wrote:
> On 1/12/23 14:54, Steffen Dettmer via samba wrote:
> > I read several articles on the internet, but I fail to understand how
> > ACL storage technically works. Of course in almost any case, ACL
> > should not only be stored but also evaluated, and for this this Samba
> > server needs to be a member of the AD domain. I think I understand
> > this, but I have a different use case. I hope someone can help and
> > possibly has a link or such.
> ACLs are not dependent on being a domain member.
> Not sure what you're aiming for as I've just skimmed your posting, but I
> guess what you're looking for is the module option
>         acl_xattr:security_acl_name = NAME
> You need a relatively new Samba version (iirc) for this.
> The security xattr namespace is not accessible from containers by
> default unless you run the container in privileged mode.
> Cheers!
> -slow
> --
> Ralph Boehme, Samba Team                 https://samba.org/
> SerNet Samba Team Lead      https://sernet.de/en/team-samba

More information about the samba mailing list