From: Brian Foster <bfoster@redhat.com>
To: Andreas Gruenbacher <agruenba@redhat.com>
Cc: xfs@oss.sgi.com
Subject: Re: Inconsistencies with trusted.SGI_ACL_{FILE,DEFAULT}
Date: Sat, 24 Oct 2015 08:57:00 -0400 [thread overview]
Message-ID: <20151024125659.GA8095@bfoster.bfoster> (raw)
In-Reply-To: <CAHc6FU5gS4BA+iTRHo1oHJMVHkLs4aa0eYd5T1ftLC9biRaxrg@mail.gmail.com>
On Fri, Oct 23, 2015 at 03:52:54PM +0200, Andreas Gruenbacher wrote:
> Hello,
>
> The usual way of manipulating a file's POSIX ACL is through the
> system.posix_acl_{access,default} xattrs. Setting
> system.posix_acl_access also sets the permission bits in the file
> mode. The acls are cached in inode->i_acl and inode->i_default_acl.
>
> On XFS, POSIX ACLs are also exposed as trusted.SGI_ACL_{FILE,DEFAULT}
> xattrs in a different value format. However, setting these xattrs does
> not update inode->i_{,default_}acl, and setting trusted.SGI_ACL_FILE
> does not update the file mode; things can get out of sync:
>
It looks like the posix_acl_* values are virtual xattrs on XFS. They get
translated to the SGI_ACL_* names before the acl code calls down into
the xattr code. The result is cached into the inode via set_cached_acl()
before the call returns.
The xattr code doesn't know anything about this so I suspect this is the
reason for the inconsistency. A direct xattr update just updates the
data on-disk and has no knowledge of the ACLs cached to the inode, the
latter of which is probably what is returned after the setxattr.
> $ touch f
> $ setfacl -m u:agruenba:rw f
> $ ls -l f
> -rw-rw-r--+ 1 root root 0 Oct 23 15:04 f
> $ getfattr -m- -d f
> # file: f
> security.selinux="unconfined_u:object_r:user_tmp_t:s0"
> system.posix_acl_access=0sAgAAAAEABgD/////AgAGAOgDAAAEAAQA/////xAABgD/////IAAEAP////8=
> trusted.SGI_ACL_FILE=0sAAAABQAAAAH/////AAYAAAAAAAIAAAPoAAYAAAAAAAT/////AAQAAAAAABD/////AAYAAAAAACD/////AAQAAA==
>
> $ chmod 0 f
> $ setfattr -n trusted.SGI_ACL_FILE -v
> 0sAAAABQAAAAH/////AAYAAAAAAAIAAAPoAAYAAAAAAAT/////AAQAAAAAABD/////AAYAAAAAACD/////AAQAAA==
> f
> $ ls -l f
> ----------+ 1 root root 0 Oct 23 15:04 /var/tmp/f
> $ getfacl f
> # file: f
> # owner: root
> # group: root
> user::---
> user:agruenba:rw- #effective:---
> group::r-- #effective:---
> mask::---
> other::---
> $ getfattr -m- -d f
> # file: f
> security.selinux="unconfined_u:object_r:user_tmp_t:s0"
> system.posix_acl_access=0sAgAAAAEAAAD/////AgAGAOgDAAAEAAQA/////xAAAAD/////IAAAAP////8=
> trusted.SGI_ACL_FILE=0sAAAABQAAAAH/////AAYAAAAAAAIAAAPoAAYAAAAAAAT/////AAQAAAAAABD/////AAYAAAAAACD/////AAQAAA==
>
> Here, the file mode and the reported value of system.posix_acl_access
> are both wrong; trusted.SGI_ACL_FILE corresponds to what's stored on
> disk.
>
> Access to trusted.* attributes is limited to users capable of
> CAP_SYS_ADMIN so ordinary users cannot cause this kind of damage, but
> this still deserves fixing.
>
Not sure there's a real use case for this, but it looks like we could
invalidate the cached ACLs if those xattrs are modified directly via the
xattr interface. Care to test the (compile tested only) hunk below? An
alternative could be to just disallow setting these xattrs directly.
Brian
> Thanks,
> Andreas
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
diff --git a/fs/xfs/xfs_xattr.c b/fs/xfs/xfs_xattr.c
index c0368151..651c2a3 100644
--- a/fs/xfs/xfs_xattr.c
+++ b/fs/xfs/xfs_xattr.c
@@ -57,7 +57,8 @@ static int
xfs_xattr_set(struct dentry *dentry, const char *name, const void *value,
size_t size, int flags, int xflags)
{
- struct xfs_inode *ip = XFS_I(d_inode(dentry));
+ struct xfs_inode *ip = XFS_I(d_inode(dentry));
+ int error;
if (strcmp(name, "") == 0)
return -EINVAL;
@@ -70,8 +71,20 @@ xfs_xattr_set(struct dentry *dentry, const char *name, const void *value,
if (!value)
return xfs_attr_remove(ip, (unsigned char *)name, xflags);
- return xfs_attr_set(ip, (unsigned char *)name,
+ error = xfs_attr_set(ip, (unsigned char *)name,
(void *)value, size, xflags);
+ /*
+ * Invalidate any cached ACLs if the user has bypassed the ACL
+ * interface.
+ */
+ if (!error && (xflags & ATTR_ROOT)) {
+ if (!strncmp(name, SGI_ACL_FILE, strlen(name)))
+ forget_cached_acl(VFS_I(ip), ACL_TYPE_ACCESS);
+ else if (!strncmp(name, SGI_ACL_DEFAULT, strlen(name)))
+ forget_cached_acl(VFS_I(ip), ACL_TYPE_DEFAULT);
+ }
+
+ return error;
}
static const struct xattr_handler xfs_xattr_user_handler = {
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2015-10-24 12:57 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 [this message]
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
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=20151024125659.GA8095@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