Message-ID: <20151018003532.GD2678@thunk.org>
Date:	Sat, 17 Oct 2015 20:35:32 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Dave Chinner <david@...morbit.com>
Cc:	Andreas Gruenbacher <agruenba@...hat.com>,
	linux-ext4 <linux-ext4@...r.kernel.org>, xfs@....sgi.com
Subject: Re: e2fsprogs: Richacl support

On Sun, Oct 18, 2015 at 09:59:10AM +1100, Dave Chinner wrote:
> For XFS userspace we also need this feature bit for xfs_repair so
> that it doesn't attempt to validate the on-disk ACL format is in a
> valid posix ACL format. IOWs, we need an on-disk feature bit to
> indicate the on-disk format of the ACL in XFS.
> 
> Further, a user could mount the ext4 fs with "norichacl,acl" to
> force the kernel to parse the rich acls as posix acls because
> without a feature bit the fs does not know what format it's acls are
> in on-disk. This will only end in tears for users.

So at least for ext4, the richacl xattr using a completely different
index, and so it's not possible to interpret the richacl as an acl.
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.

We're also not trying to validate the on-disk ACL format at all using
e2fsck, just as we're not trying to validate say, the SELinux xattr.
They are just bags of bits as far as e2fsck is concerned.  So for that
reason, at least as the patches I've seen for richacl for ext4,
e2fsprogs doesn't actually need a file system feature bit at all.  We
could in theory use the 1.42 version of e2fsck against an ext4 file
system with richacl, and modulo the incompat flag, there wouldn't be
any problems from e2fsck point of view.

What Andreas G. has said is that the only problem is if the file
system is mounted read/write, and someone creates an inode on a
non-richacl knowledgeable kernel, the inode would get created w/o an
richacl.  This might be surprising to the user if he or she was
expecting richacl semantics, but that would only happen if they had
say, enabled richacl's on a distribution that had full richacl support
(including the richacl userspace utilities so they could set and get
richacl entries), and then booted an older kernel on that
distribution.  This doesn't seem like _that_ likely a scenario, but I
suppose it could happen.  And whether you call the file system
"inconsistent" really depends on your point of view.  From the
perspective of fsck, which for ext4 is completely, happily ignorant of
richacl support, it's not inconsistent and all of the inodes are
valid.

> I asked this same question on the kernel side of things. While I
> think that from an "on-disk consistency" POV using RO_INCOMPAT would
> be fine, from a user visible POV the behaviour won't be compatible
> and so INCOMPAT makes sense from that perspective.

If you believe that the only real use of richacl will be primarily for
supporting Samba and NFSv4 servers, then using a read-only compat
feature flag isn't that terrible, and it might be helpful in the case
of someone using a rescue media that hasn't been updated yet to be
able to access the system --- since it seems unlikely that the user
would try to launch a Samba or NFSv4 server from a rescue CD.

But I different people of good will can differ with each other, and at
the end of the day I don't think it makes *that* much difference
unless we drop the use of the feature flag entirely.  Given that
systemd has infected all of the distributions, and systemd is getting
more and more tightly integrated into modern kernel features w/o
offerring backwards compatibility, it seems very likely to me that you
wouldn't even be able to *boot* a downrev kernel on a modern
distribution that has richacl support without seeing systemd or its
dependencies explode into millions of tiny pleaces, so I'm not that
terribly worried one way or another.  :-)

						- 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

Powered by blists - more mailing lists