All of lore.kernel.org
 help / color / mirror / Atom feed
From: hubcap@kernel.org
To: torvalds@linux-foundation.org
Cc: Mike Marshall <hubcap@omnibond.com>, linux-fsdevel@vger.kernel.org
Subject: [RFC] orangefs: posix acl fix...
Date: Wed, 29 Jul 2020 10:42:48 -0400	[thread overview]
Message-ID: <20200729144248.1381026-1-hubcap@kernel.org> (raw)

From: Mike Marshall <hubcap@omnibond.com>

Al Viro pointed out that I broke some acl functionality...

 * ACLs could not be fully removed
 * posix_acl_chmod would be called while the old ACL was still cached
 * new mode propagated to orangefs server before ACL.

... when I tried to make sure that modes that got changed as a
result of ACL-sets would be sent back to the orangefs server.

Not wanting to try and change the code without having some cases to
test it with, I began to hunt for setfacl examples that were expressible
in pure mode. Along the way I found examples like the following
which confused me:

  user A had a file (/home/A/asdf) with mode 740
  user B was in user A's group
  user C was not in user A's group

  setfacl -m u:C:rwx /home/A/asdf

  The above setfacl caused ls -l /home/A/asdf to show a mode of 770,
  making it appear that all users in user A's group now had full access
  to /home/A/asdf, however, user B still only had read acces. Madness.

Anywho, I finally found that the above (whacky as it is) appears to
be "posixly on purpose" and explained in acl(5):

  If the ACL has an ACL_MASK entry, the group permissions correspond
  to the permissions of the ACL_MASK entry.

Signed-off-by: Mike Marshall <hubcap@omnibond.com>
---
 fs/orangefs/acl.c | 19 ++++++++++---------
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/fs/orangefs/acl.c b/fs/orangefs/acl.c
index eced272a3c57..a25e6c890975 100644
--- a/fs/orangefs/acl.c
+++ b/fs/orangefs/acl.c
@@ -122,6 +122,8 @@ int orangefs_set_acl(struct inode *inode, struct posix_acl *acl, int type)
 	struct iattr iattr;
 	int rc;
 
+	memset(&iattr, 0, sizeof iattr);
+
 	if (type == ACL_TYPE_ACCESS && acl) {
 		/*
 		 * posix_acl_update_mode checks to see if the permissions
@@ -138,18 +140,17 @@ int orangefs_set_acl(struct inode *inode, struct posix_acl *acl, int type)
 			return error;
 		}
 
-		if (acl) {
-			rc = __orangefs_set_acl(inode, acl, type);
-		} else {
+		if (inode->i_mode != iattr.ia_mode)
 			iattr.ia_valid = ATTR_MODE;
-			rc = __orangefs_setattr(inode, &iattr);
-		}
 
-		return rc;
-
-	} else {
-		return -EINVAL;
 	}
+
+	rc = __orangefs_set_acl(inode, acl, type);
+
+	if (!rc && (iattr.ia_valid == ATTR_MODE))
+		rc = __orangefs_setattr(inode, &iattr);
+
+	return rc;
 }
 
 int orangefs_init_acl(struct inode *inode, struct inode *dir)
-- 
2.25.4


                 reply	other threads:[~2020-07-29 14:43 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20200729144248.1381026-1-hubcap@kernel.org \
    --to=hubcap@kernel.org \
    --cc=hubcap@omnibond.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /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.