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

["J. Bruce Fields" <bfields@fieldses.org>]

On Wed, Jan 14, 2015 at 07:01:35AM -0500, Jeff Layton wrote:
> On Wed, 14 Jan 2015 09:53:10 +0100
> Andreas Gruenbacher <agruenba@redhat.com> wrote:
> > I really don't think that changing the existing POSIX ACL behavior is an 
> > option here, or that representing POSIX ACLs as richacls internally 
> > makes a lot of sense. We'll be much better off having both models side 
> > by side.

OK, fair enough, it may not be worth the trouble.

> > 
> > Converting existing POSIX ACLs into richacls, for example for converting 
> > an entire file system, possibly offline, is relatively simple and 
> > straight forward -- and will be needed -- with the caveat that 
> > permissions will then start to accumulate.

Please don't say it that way or people are going to think we're not
handling cases like mode 026--we should definitely insert DENYs as as
necessary.  So the only inaccuracy is that weird corner case with group
ACEs.  Which is worth a footnote, sure, but that's all.

--b.

> > Converting richacls into POSIX ACLs may occasionally be needed when 
> > migrating something back as well, but this operation is lossy in 
> > general, likely slow, there could be different policies like failing or 
> > dropping permissions when something cannot be represented exactly. By 
> > representing POSIX ACLs as richacls internally, that more complicated 
> > conversion would be needed all the time, even in the kernel, though.
> > 
> 
> FWIW, at the last LSF we had a discussion around richacls and Aneesh
> was present. The tentative decision at that time was that filesystems
> should store _either_ richacls or posix acls, and that decision should
> be made at fs creation time.
> 
> If you need to convert to the other scheme, then the understanding was
> that you'd either recreate the filesystem, or potentially do some sort
> of in-place conversion with a specialized tool.
> 
> I think aiming for that sort of scheme makes the most sense as it
> covers the vast majority of use-cases and keeps undue complexity out of
> the kernel.
> 
> -- 
> Jeff Layton <jlayton@primarydata.com>