An interface to share-level permissions through the VFS or another shared library ...
realrichardsharpe at gmail.com
Sat Jun 16 08:55:10 MDT 2012
On Fri, Jun 15, 2012 at 10:53 PM, Volker Lendecke
<Volker.Lendecke at sernet.de> 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.
Yes, this was my motivation ... how can we reduce the different types
of objects for replication.
Further to your comment about the registry, I believe that I mentioned
a while ago that Windows actually puts share-level permissions in the
registry, so your comment is an appropriate reminder that I should do
something about implementing that approach.
> 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.
Well, putting them into an xattr is an implementation detail. The
modular interface I was thinking of was having it done via the VFS,
but perhaps that is simply overloading the VFS too much.
It could be another loadable shared library (as could, say, RPC implemenations).
However, at the moment, this is just me thinking out aloud.
(reposted my response to Volker for everyone to see.)
More information about the samba-technical