All of lore.kernel.org
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Andreas Gruenbacher <agruenba@redhat.com>
Cc: linux-ext4 <linux-ext4@vger.kernel.org>, xfs@oss.sgi.com
Subject: Re: e2fsprogs: Richacl support
Date: Sun, 18 Oct 2015 17:44:56 -0400	[thread overview]
Message-ID: <20151018214456.GM2678@thunk.org> (raw)
In-Reply-To: <CAHc6FU6U-r4YjxdvhW_OAmdekzK-tBT62Hs_JBYFB0V65qDw4w@mail.gmail.com>

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

  reply	other threads:[~2015-10-18 21:44 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-16 16:03 e2fsprogs: Richacl support Andreas Gruenbacher
2015-10-16 23:16 ` Theodore Ts'o
2015-10-17  0:22   ` Andreas Gruenbacher
2015-10-17 14:39     ` Theodore Ts'o
2015-10-17 22:59       ` Dave Chinner
2015-10-18  0:35         ` Theodore Ts'o
2015-10-18 20:46           ` Andreas Gruenbacher
2015-10-18 21:44             ` Theodore Ts'o [this message]
2015-10-18 22:46               ` Andreas Gruenbacher
2015-10-19  0:17                 ` Theodore Ts'o

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151018214456.GM2678@thunk.org \
    --to=tytso@mit.edu \
    --cc=agruenba@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.