Current approaches to ACL handling

Jeremy Allison jra at
Wed Oct 17 06:57:47 MDT 2012

On Tue, Oct 16, 2012 at 10:58:02AM -0400, J. Bruce Fields wrote:
> On Mon, Oct 08, 2012 at 02:53:36PM -0500, Christopher R. Hertel wrote:
> > If I understood Alexander's suggestion, it was to implement Windows
> > ACLs in the filesystem/kernel.  That would mean that Samba would no
> > longer need to adapt because the semantics would be what we'd
> > expect.
> > 
> > On the other hand, how would the kernel go about enforcing some of
> > the more obscure permissions for non-Samba processes?  How would NFS
> > interpret the ACLs?  What about local processes?  Which permissions
> > would be exposed to the local user and which would not?  The
> > adaptations would have to move, probably into the kernel with the
> > new ACL type.
> I think this is the most recent posting of the richacl patches:
> It includes enforcement of new permission bits; e.g., write attributes:
> delete and delete child:
> file vs directory creation:
> So they are of course intended to be exposed and enforced consistently
> against local, NFS, and Samba users.
> Review is welcome; if you see anything specific missing, please let us
> know.

So the last comment on this patchset was from Christoph Hellwig,
which stated:

> Please as a first thing submit the various small cleanups indepent
> of the other changes.  If you can't even those in there's no point
> in trying. 


> I also really hate all the duplication - I want to see a really good
> reason why all this code needs to be duplicated.  Just look at
> the mess done to check_acl and the ACL caching in the inode and
> any normal person would throw up.  There is absolutely no reason
> to not implement Posix ACLs as a subset of the NFSv4 ACL (not actually
> a subset in the strict mathematical sense, but close enough).

which never got done. I think it's possible to re-do
POSIX ACLs as a subset of RichACLs but that's a re-write
of the patchset.


More information about the samba-technical mailing list