From mboxrd@z Thu Jan 1 00:00:00 1970 From: "'J. Bruce Fields'" Subject: Re: [Lsf-pc] [LSF/MM ATTEND] Richacls Date: Tue, 13 Jan 2015 15:24:36 -0500 Message-ID: <20150113202436.GC4156@fieldses.org> 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> <20150113164802.GA5830@samba2> <54B5548E.5030808@redhat.com> <20150113174029.GA4156@fieldses.org> <20150113180458.GF5830@samba2> <017d01d02f6a$a2e9e220$e8bda660$@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: 'Jeremy Allison' , 'Andreas Gruenbacher' , 'Jan Kara' , linux-fsdevel@vger.kernel.org, lsf-pc@lists.linux-foundation.org To: Frank Filz Return-path: Received: from fieldses.org ([174.143.236.118]:53968 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751113AbbAMUYk (ORCPT ); Tue, 13 Jan 2015 15:24:40 -0500 Content-Disposition: inline In-Reply-To: <017d01d02f6a$a2e9e220$e8bda660$@mindspring.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, Jan 13, 2015 at 11:53:42AM -0800, Frank Filz wrote: > > On Tue, Jan 13, 2015 at 12:40:29PM -0500, J. Bruce Fields wrote: > > > On Tue, Jan 13, 2015 at 06:23:26PM +0100, Andreas Gruenbacher wrote: > > > > On 01/13/2015 05:48 PM, Jeremy Allison wrote: > > > > >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. > > > > > > > > On of the differences is that permissions in POSIX ACLs do > > > > accumulate, while in NFSv4 and CIFS ACLs, and therefore also > > > > richacls, they do not. So the two models are really not > > > > interchangeable, however annoying that may be. > > I think Andreas got do and do not reversed (though looks like everyone read > it the right way...) > > > > > For example, with the following POSIX ACL, a non-root process in > > > > group 5001 and 5002 would not be allowed to open f with O_RDWR, only > > > > with O_RDONLY *or* O_WRONLY. > > > > > > > > # file: f > > > > # owner: root > > > > # group: root > > > > user::rw- > > > > group::rw- > > > > group:5001:r-- > > > > group:5002:-w- > > > > mask::rw- > > > > other::--- > > > > > > > > In all the other ACL models, the process would be allowed to open f > > > > with O_RDWR. > > Hasn't this been resolved in in knfsd by use of DENY ACEs in converting the > POSIX ACL to NFS v4? > > I just had a question though... > > Can a process that is in both groups open two file descriptors, one > read-only and one write-only? I think so. Yep. > Assuming so, what happens with NFS v4 where the 2nd open results in an > open-upgrade over the wire to read-write? If anyone cares: currently knfsd will attempt a single read-write open if a client does a read-write open, but if a client (for example) opens for read and then upgrades for write, nfsd will do a read-only open and then a write-only open. So given the above acl that open+upgrade sequence would succeed where the read-write open would fail. > > > If we modified the behavior to permit O_RDWR in this case, would that > > > cause anyone a problem? > > > > Hmmmm. It changes userspace visible behavior. I can't think of any reason > > anyone would be relying on this (other than bugs :-) but still... > > Yea, I would be wary of changing user space behavior. At the least, it MIGHT > cause someone's conformance test to fail. On the other hand, the POSIX ACL > draft never become a standard so no one would really have a complaint if > Linux's implementation were slightly different... I doubt anyone worries about that so much as about breaking something on upgrade due to someone expecting the older behavior. That sounds unlikely, though. --b.