From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Allison Subject: Re: [Lsf-pc] [LSF/MM ATTEND] Richacls Date: Tue, 13 Jan 2015 08:48:02 -0800 Message-ID: <20150113164802.GA5830@samba2> References: <1626890778.1513173.1421087867777.JavaMail.zimbra@redhat.com> <1137663039.1544780.1421096804147.JavaMail.zimbra@redhat.com> <20150112223016.GB1940@fieldses.org> <20150113101435.GA28924@quack.suse.cz> <54B534C3.3090608@redhat.com> Reply-To: Jeremy Allison Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jan Kara , "J. Bruce Fields" , linux-fsdevel@vger.kernel.org, lsf-pc@lists.linux-foundation.org To: Andreas Gruenbacher Return-path: Received: from fn.samba.org ([216.83.154.106]:39959 "EHLO mail.samba.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753248AbbAMQsF (ORCPT ); Tue, 13 Jan 2015 11:48:05 -0500 Content-Disposition: inline In-Reply-To: <54B534C3.3090608@redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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.