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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
