linux-ext4 - Re: e2fsprogs: Richacl support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 18 Oct 2015 17:44:56 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Andreas Gruenbacher <agruenba@...hat.com>
Cc:	Dave Chinner <david@...morbit.com>,
	linux-ext4 <linux-ext4@...r.kernel.org>, xfs@....sgi.com
Subject: Re: e2fsprogs: Richacl support

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