> 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. That certainly makes life a lot simplere. > > > 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. Yes, definitely, any conversion tool should make a best effort. A conversion tool could also have options to direct how it translates certain tricky constructions. So if the sysadmin knows groups are used to remove permissions, then the conversion tool could be directed to insert a DENY ACE after every group ACE (such a user SHOULD NOT have this construct anyway, it wouldn't make sense). > > > 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. Hmm, poor cp and tar (and other tools) will be thrown into shark infested waters... I assume the initial caveat will be that anything that copies a file from a filesystem that uses POSIX to a filesystem that uses RICHACL or visa versa will NOT copy the ACL. > > 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. Yea, that sounds good. Frank -- 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
