Re: [Lsf-pc] [LSF/MM ATTEND] Richacls

[Jeremy Allison <jra@samba.org>]

On Tue, Jan 13, 2015 at 04:07:47PM +0100, Andreas Gruenbacher wrote:
> On 01/13/2015 11:14 AM, Jan Kara wrote:
> >As far as I remember (and I'm sorry if I'm too explicit here) the main
> >issue is to find a way of implementing the features necessary for RichACLs
> >in a way acceptable for Al and Christoph Hellwig. I specifically remember
> >Christoph having strong opinions on the rich ACL features as such.
> 
> I'm aware of two major kinds of issues: first, if the permission
> model as implemented in the current (old) patch set makes sense and
> if a simplified model isn't enough, and second, if richacls really
> need to be represented differently than POSIX ACLs which are already
> in the kernel (struct posix_acl).
> 
> I think the features that the permission model that the richacl
> patches implement are needed and that a simplified model wouldn't be
> useful. As far as the implementation goes, there are significant
> differences among the two models (richacl entries can either allow
> or deny something, the order of entries matters, and instead of
> having "access" as well as default acls as separate objects,
> inheritance is determined by flags of the acl and its entries). But
> that doesn't require that different objects need to be used for
> representing the two kinds of acls: shoving both models into the
> same object type would make the details slightly more difficult to
> understand but those details would be somewhat hidden
> at the "layer above" as well. I'll try if that approach holds any value.

My understanding of Christoph's objection (although I'm sure
he can chime in himself :-) was that he wanted to see POSIX
ACLs reworked as a mapping on top of RichACLs, so that ultimately
RichACLs would be the only on-disk format of the EA.

I think that is doable, as I think any POSIX ACL can be represented
as an underlying RichACL, just not the reverse.