usershare acl parser?

Jeremy Allison jra at
Sun Dec 11 17:38:11 GMT 2005

On Sun, Dec 11, 2005 at 10:42:18PM +1100, tridge at wrote:
> SEC_STD_SYNCHRONIZE won't be useful on a share root, but the others
> definately mean something

This was just an example :-).

> well, playing devils advocate, how will you control the inheritance,
> which controls what ACL will be used on files created in the root of
> the share?

Historically we've always used the attributes on the sharing directory,
in the same way inheritance is used within the share. I don't see why
we'd need to change that.

> How will you allow/deny changing attributes on the share? (such as
> volume name). How will you enable auditing controls? 
> You may well be right that a full ACL is more than most people need,
> but I don't think its true to say that a broader ACL capability is
> useless.

Everyone seems to be mistaken in that they think this will be the
*only* way to specify a share acl. It's probably my fault for not
posting the design first (but I'm working it out with the code).

Remember, the share acl tdb stores *full* windows acls with all
the insane semantics people arguing with me seem to love :-). The
usershare acl is *one* way of creating simple share ACLs
that go into that store.

If you want to add a "full acl parser" that then extracts
these ndr-marshalled ACLs and adds the ability to maipulate 
all the insane bits, then be my guest :-).

I just don't think that should be the first interface that
users who just want to run a simple command line tool to
share a folder should see.


More information about the samba-technical mailing list