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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
