public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: Andreas Gruenbacher <agruenba@redhat.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 2/4] xfs: SGI ACLs: Fix caching and mode setting
Date: Mon, 26 Oct 2015 15:00:45 -0400	[thread overview]
Message-ID: <20151026190045.GE59738@bfoster.bfoster> (raw)
In-Reply-To: <CAHc6FU5a-20aTceoKKZNmk=v+WQt+xLtSGZPo4yXN7Uq9ZDWOA@mail.gmail.com>

On Mon, Oct 26, 2015 at 04:39:20PM +0100, Andreas Gruenbacher wrote:
> On Mon, Oct 26, 2015 at 3:02 PM, Brian Foster <bfoster@redhat.com> wrote:
> > Finally, another random thought... another way to approach this whole
> > thing might be just to redirect the SGI_FILE_* xattr calls to the
> > system.posix_acl_* calls.
> 
> You mean silently changing the binary format of those attributes?
> That's the worst thing we could possibly do.
> 

It would change an implicit error/failure to an explicit one.
Regardless, I realized this particular approach is kind of pointless
anyways (as noted in my other mail).

Note that I'm not necessarily against what we're doing here, it might
very well be required. I'm just trying to step back and understand the
big picture before we go and put a band-aid on the immediate problem and
call it solved. To me, the ideal overall situation is that this
attribute is hidden and anybody that cares about ACLs can get/set them
through the appropriate ACL interface (the system.posix_acl_* xattrs).
The question is whether we can get anywhere close to that without
breaking things.

> > The SGI_FILE_* xattr data changes along with the required conversions
> > and whatnot, but then at least we expose data in a more generic format.
> 
> I really doubt that we can get rid of those attributes.
> 

The problem seems to boil down to the fact that the by-handle operations
(ATTRLIST_BY_HANDLE) don't include the system.posix_acl_* attributes,
and thus these aren't tracked by applications that use that interface
(such as xfsdump). I was hoping that whatever might have looked at the
SGI_ACL_* attrs would also have seen the posix_acl_* attr and thus we
could potentially get away with something like ignoring SGI_ACL_
operations (rather than failing them) without losing any information,
but that does not appear to be the case.

It still might be worth considering drawing a line in the sand (for
example, v5 filesystems or later) to deprecate the SGI_ACL_* xattrs. For
example:

- Fix the by-handle ATTR mechanisms to include the system.posix_acl_*
  xattrs.
- Hide the SGI_ACL_* xattrs from xattr lists.
- Add the SGI_ACL_* setxattr() validation as we're doing here for
  backwards compatibility, but include a deprecation log message warning
  in favor of using the above.
- At some point in the future, disallow the ability to get/set the
  SGI_ACL_* xattrs.

This also assumes there isn't some other reason we have SGI_ACL_*
exposed that I'm not aware of, which could certainly be the case.

Brian

> The patches in this queue don't "change" the format of those
> attributes, they only fix them for use in UID/GID  namespaces where
> they are currently broken. Validation when setting those xattrs could
> be removed, allowing sysadmins to set acls which the kernel and
> xfs_repair would reject; it seems rather pointless though.
> 
> Thanks,
> Andreas

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2015-10-26 19:00 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-23 13:52 Inconsistencies with trusted.SGI_ACL_{FILE,DEFAULT} Andreas Gruenbacher
2015-10-24 12:57 ` Brian Foster
2015-10-24 13:58   ` Andreas Gruenbacher
2015-10-24 15:22     ` Brian Foster
2015-10-24 15:36       ` Brian Foster
2015-10-24 21:05       ` Andreas Gruenbacher
2015-10-24 21:16         ` [PATCH 0/4] xfs: SGI ACL Fixes Andreas Gruenbacher
2015-10-24 21:16           ` [PATCH 1/4] xfs: Validate the length of on-disk ACLs Andreas Gruenbacher
2015-10-24 21:16           ` [PATCH 2/4] xfs: SGI ACLs: Fix caching and mode setting Andreas Gruenbacher
2015-10-26 14:02             ` Brian Foster
2015-10-26 15:39               ` Andreas Gruenbacher
2015-10-26 19:00                 ` Brian Foster [this message]
2015-10-24 21:16           ` [PATCH 3/4] xfs: SGI ACLs: Map uid/gid namespaces Andreas Gruenbacher
2015-10-26 21:46             ` Dave Chinner
2015-10-27 15:55               ` Andreas Gruenbacher
2015-10-27 19:55                 ` Dave Chinner
2015-10-27 21:10                   ` Andreas Gruenbacher
2015-10-27 22:37                     ` Dave Chinner
2015-10-27 23:38                       ` Andreas Gruenbacher
2015-10-24 21:16           ` [PATCH 4/4] xfs: SGI ACLs: Prepare for richacls Andreas Gruenbacher
2015-10-26 20:15             ` Andreas Gruenbacher
2015-10-26 14:02           ` [PATCH 0/4] xfs: SGI ACL Fixes Brian Foster
2015-10-26 21:32       ` Inconsistencies with trusted.SGI_ACL_{FILE,DEFAULT} Dave Chinner
2015-10-26 23:52         ` Andreas Gruenbacher
2015-10-27  5:30           ` Dave Chinner
2015-10-27 10:56             ` Andreas Gruenbacher
2015-10-27 20:18               ` Dave Chinner
2015-10-27 21:39                 ` Andreas Gruenbacher
2015-10-27 22:38                   ` Dave Chinner
2015-10-27 11:31             ` Brian Foster

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=20151026190045.GE59738@bfoster.bfoster \
    --to=bfoster@redhat.com \
    --cc=agruenba@redhat.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox