From mboxrd@z Thu Jan 1 00:00:00 1970 From: Theodore Ts'o Subject: Re: e2fsprogs: Richacl support Date: Sun, 18 Oct 2015 17:44:56 -0400 Message-ID: <20151018214456.GM2678@thunk.org> References: <20151016231615.GF15011@thunk.org> <20151017143951.GA2678@thunk.org> <20151017225910.GT27164@dastard> <20151018003532.GD2678@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: linux-ext4 , xfs@oss.sgi.com To: Andreas Gruenbacher Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com List-Id: linux-ext4.vger.kernel.org On Sun, Oct 18, 2015 at 10:46:23PM +0200, Andreas Gruenbacher wrote: > > The only question is whether we pay attention to the richacl acl's at > > all. One thing that's not clear to me is what VFS is supposed to do > > if an inode has both an Posix ACL xattr and a Richacl xattr at the > > same time. > > The VFS will either look for POSIX ACLs or for a richacl; it won't > even notice if both are present. How does this work in practice? Does it look for richacl's first, and if it doesn't find it, it will then look for a Posix ACL, or vice versa? > Right now, filesystems that e2fsck is perfectly happy with can still > cause errors when used. It would be nice to fix that. > > With POSIX ACLs, this problem is slightly less severe because the ACL > isn't looked at for the owner; it would even be possible to replace a > corrupted POSIX ACL. Richacls unfortunately don't allow this > optimization. Is there code we can use to verify a richacl, and if it's corrupted, what are the options about how we can fix it? Or do we just remove it, and just use the inode's i_uid field for the owner instead of whatever might be in the richacl? Ideally, if you can send the patch to add support to validate / fix Richacl's in e2fsck, that would be great. > This really should be a feature flag and not a mount option, it just > doesn't make sense to switch at mount time. > > From this discussion, I'm even more convinced that we should use an > incompat feature rather than a ro-incompat feature. OK, let's go with that. - Ted _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs