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

[Jan Kara <jack@suse.cz>]

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 <jack@suse.cz>
SUSE Labs, CR