From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kara Subject: Re: [Lsf-pc] [LSF/MM ATTEND] Richacls Date: Tue, 13 Jan 2015 22:31:03 +0100 Message-ID: <20150113213103.GH28924@quack.suse.cz> 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> <20150113210440.GG28924@quack.suse.cz> <20150113211612.GD4156@fieldses.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jan Kara , Andreas Gruenbacher , Jeremy Allison , linux-fsdevel@vger.kernel.org, lsf-pc@lists.linux-foundation.org To: "J. Bruce Fields" Return-path: Received: from cantor2.suse.de ([195.135.220.15]:46845 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751176AbbAMVbI (ORCPT ); Tue, 13 Jan 2015 16:31:08 -0500 Content-Disposition: inline In-Reply-To: <20150113211612.GD4156@fieldses.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue 13-01-15 16:16:13, J. Bruce Fields wrote: > On Tue, Jan 13, 2015 at 10:04:40PM +0100, Jan Kara wrote: > > On Tue 13-01-15 12:40:29, 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. > > > > > > > > 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. > > > > > > If we modified the behavior to permit O_RDWR in this case, would that > > > cause anyone a problem? > > As others noted, this changes user visible behavior and I don't think we > > can do that. In the discussion about user namespaces, we for example > > specifically disallowed unpriviledged process to drop some group membership > > exactly because it can actually result in process suddently being able to > > access some files and reportedly there are setups which are using group > > membership to *restrict* access. > > Right, but look at the case above carefully again--it's *much* more > special than the one the container people hit. > > You can absolutely still represent weird modes like 026 with a Richacl > and it will deny permissions in the traditional way. Ah, OK. You are right that Rich ACLs can express the use of a group to restrict permissions. > Using the usual "if a tree fell in a forest and nobody heard it..." > criterion, I think this change would be unlikely to cause us trouble. On a second thought I agree. Honza -- Jan Kara SUSE Labs, CR