An interface to share-level permissions through the VFS or another shared library ...

Richard Sharpe realrichardsharpe at
Sat Jun 16 08:59:43 MDT 2012

On Sat, Jun 16, 2012 at 7:15 AM, simo <idra at> wrote:
> On Sat, 2012-06-16 at 07:53 +0200, Volker Lendecke wrote:
>> On Fri, Jun 15, 2012 at 12:24:04PM -0700, Richard Sharpe wrote:
>> > Hi folks,
>> >
>> > Currently, as far as I can see, the interface to share-level ACLs is
>> > private within Samba, and they re currently stored in a TDB.
>> >
>> > However, some system integrators who are doing replication, might
>> > prefer to keep this information in XATTRs so they don't have to
>> > replicate different types of objects ...
>> >
>> > Of course, this does raise other issues. In particular, co-ordinating
>> > updates by multiple users and issues of application-consistency with
>> > respect to replication etc.
>> >
>> > If we were to entertain a VFS-level interface, it would have to go in
>> > the disk-operations group, I would imagine.
>> >
>> > Any comments/thoughts?
>> This is what some system integrators use ctdb with its
>> persistent databases for. If we were to move those share
>> acls somewhere else, I would prefer the registry. For
>> automated, script-based configuration, the registry is very
>> handy. net conf setparm is easier to call than
>> parsing/printing an smb.conf.
>> This would then mean that the integrator has to replicate
>> files and the registry. That's two kinds of objects, not
>> other tdbs as well.
>> If you are about to put the share acl into an xattr, please
>> make that a modular interface, so that we can do other
>> approaches as well.
> I am a bit opposed to an xattr-based approach, and the reason is simple:
> share != directory on disk.
> Samba can be configured to have multiple shares with different
> permissions that correspond to the same directory on disk.
> Or a single share (the special home share) that corresponds to multiple
> directories.
> Also the share definition can vary depending on expansions in the path
> attribute in theory.
> So an xattr on the disk is a very bad match and would quickly lead to
> surprises.
> Last and not least, the TDB can be upgraded at samba startup time if we
> ever need to change something, with xattrs it becomes a lot harder, esp
> if things change around and you'd have to wrestle with always checking
> if the attr you just fetched is of the right version of it needs
> conversion and what not. It also makes backups a little more difficult.

This is an important consideration, in general, although individual
integrators might not use all that flexibility.

> Please keep using the registry, where the key name is the share name and
> use the RPC interface to manage these objects.
> It really is the simplest interface, and we do not need to make this
> code path more complicated IMHO.

Well, people who are running Samba and who are doing replication do
not want to use RPCs to get at this information. They want to have
some sort of local interface with some sort of manageable consistency
semantics. At least, that is what I am hearing.

However, maybe they should be educated to use the RPC interface, since
they are likely using RPC for their replication implementation as

Richard Sharpe

More information about the samba-technical mailing list