From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: "J. Bruce Fields" <bfields@fieldses.org>, agruen@linbit.com
Cc: agruen@kernel.org, akpm@linux-foundation.org,
dhowells@redhat.com, linux-fsdevel@vger.kernel.org,
linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH -V6 14/26] richacl: Permission mapping functions
Date: Thu, 08 Sep 2011 15:57:37 +0530 [thread overview]
Message-ID: <87aaaf5nxi.fsf@skywalker.in.ibm.com> (raw)
In-Reply-To: <20110907212400.GH8074@fieldses.org>
On Wed, 7 Sep 2011 17:24:00 -0400, "J. Bruce Fields" <bfields@fieldses.org> wrote:
> On Mon, Sep 05, 2011 at 10:55:36PM +0530, Aneesh Kumar K.V wrote:
> > From: Andreas Gruenbacher <agruen@kernel.org>
> >
> > We need to map from POSIX permissions to NFSv4 permissions when a
> > chmod() is done, from NFSv4 permissions to POSIX permissions when an acl
> > is set (which implicitly sets the file permission bits), and from the
> > MAY_READ/MAY_WRITE/MAY_EXEC/MAY_APPEND flags to NFSv4 permissions when
> > doing an access check in a richacl.
> >
> > Signed-off-by: Andreas Gruenbacher <agruen@kernel.org>
> > Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> > ---
> > fs/richacl_base.c | 118 +++++++++++++++++++++++++++++++++++++++++++++++
> > include/linux/richacl.h | 46 ++++++++++++++++++
> > 2 files changed, 164 insertions(+), 0 deletions(-)
> >
> > diff --git a/fs/richacl_base.c b/fs/richacl_base.c
> > index 3536626..d55b436 100644
> > --- a/fs/richacl_base.c
> > +++ b/fs/richacl_base.c
> > @@ -69,6 +69,124 @@ richacl_clone(const struct richacl *acl)
> > }
> >
> > /**
> > + * richacl_mask_to_mode - compute the file permission bits which correspond to @mask
> > + * @mask: %ACE4_* permission mask
> > + *
> > + * See richacl_masks_to_mode().
> > + */
> > +static int
> > +richacl_mask_to_mode(unsigned int mask)
> > +{
> > + int mode = 0;
> > +
> > + if (mask & ACE4_POSIX_MODE_READ)
> > + mode |= MAY_READ;
> > + if (mask & ACE4_POSIX_MODE_WRITE)
> > + mode |= MAY_WRITE;
> > + if (mask & ACE4_POSIX_MODE_EXEC)
> > + mode |= MAY_EXEC;
> > +
> > + return mode;
> > +}
> > +
> > +/**
> > + * richacl_masks_to_mode - compute the file permission bits from the file masks
> > + *
> > + * When setting a richacl, we set the file permission bits to indicate maximum
> > + * permissions: for example, we set the Write permission when a mask contains
> > + * ACE4_APPEND_DATA even if it does not also contain ACE4_WRITE_DATA.
> > + *
> > + * Permissions which are not in ACE4_POSIX_MODE_READ, ACE4_POSIX_MODE_WRITE, or
> > + * ACE4_POSIX_MODE_EXEC cannot be represented in the file permission bits.
> > + * Such permissions can still be effective, but not for new files or after a
> > + * chmod(), and only if they were set explicitly, for example, by setting a
> > + * richacl.
> > + */
> > +int
> > +richacl_masks_to_mode(const struct richacl *acl)
> > +{
> > + return richacl_mask_to_mode(acl->a_owner_mask) << 6 |
> > + richacl_mask_to_mode(acl->a_group_mask) << 3 |
> > + richacl_mask_to_mode(acl->a_other_mask);
> > +}
> > +EXPORT_SYMBOL_GPL(richacl_masks_to_mode);
> > +
> > +/**
> > + * richacl_mode_to_mask - compute a file mask from the lowest three mode bits
> > + *
> > + * When the file permission bits of a file are set with chmod(), this specifies
> > + * the maximum permissions that processes will get. All permissions beyond
> > + * that will be removed from the file masks, and become ineffective.
> > + *
> > + * We also add in the permissions which are always allowed no matter what the
> > + * acl says.
> > + */
> > +unsigned int
> > +richacl_mode_to_mask(mode_t mode)
> > +{
> > + unsigned int mask = ACE4_POSIX_ALWAYS_ALLOWED;
> > +
> > + if (mode & MAY_READ)
> > + mask |= ACE4_POSIX_MODE_READ;
> > + if (mode & MAY_WRITE)
> > + mask |= ACE4_POSIX_MODE_WRITE;
> > + if (mode & MAY_EXEC)
> > + mask |= ACE4_POSIX_MODE_EXEC;
> > +
> > + return mask;
> > +}
> > +
> > +/**
> > + * richacl_want_to_mask - convert the iop->permission want argument to a mask
> > + * @want: @want argument of the permission inode operation
> > + *
> > + * When checking for append, @want is (MAY_WRITE | MAY_APPEND).
> > + *
> > + * Richacls use the iop->may_create and iop->may_delete hooks which are
> > + * used for checking if creating and deleting files is allowed. These hooks do
> > + * not use richacl_want_to_mask(), so we do not have to deal with mapping
> > + * MAY_WRITE to ACE4_ADD_FILE, ACE4_ADD_SUBDIRECTORY, and ACE4_DELETE_CHILD
> > + * here.
> > + */
> > +unsigned int
> > +richacl_want_to_mask(int want)
> > +{
> > + unsigned int mask = 0;
> > +
> > + if (want & MAY_READ)
> > + mask |= ACE4_READ_DATA;
> > + if (want & (MAY_APPEND |
> > + MAY_CREATE_FILE | MAY_CREATE_DIR |
> > + MAY_DELETE_CHILD | MAY_DELETE_SELF |
> > + MAY_TAKE_OWNERSHIP | MAY_CHMOD | MAY_SET_TIMES)) {
> > + if (want & MAY_APPEND)
> > + mask |= ACE4_APPEND_DATA;
> > + else if (want & MAY_DELETE_SELF)
> > + mask |= ACE4_DELETE;
> > + else if (want & MAY_TAKE_OWNERSHIP)
> > + mask |= ACE4_WRITE_OWNER;
> > + else if (want & MAY_CHMOD)
> > + mask |= ACE4_WRITE_ACL;
> > + else if (want & MAY_SET_TIMES)
> > + mask |= ACE4_WRITE_ATTRIBUTES;
> > + else {
> > + if (want & MAY_CREATE_FILE)
> > + mask |= ACE4_ADD_FILE;
> > + if (want & MAY_CREATE_DIR)
> > + mask |= ACE4_ADD_SUBDIRECTORY;
> > + if (want & MAY_DELETE_CHILD)
> > + mask |= ACE4_DELETE_CHILD;
> > + }
>
> Possibly dumb question: why isn't this whole function a simple series of
> if's, one for each MAY_ bit?
>
> I guess you're using knowledge about the callers to know that, for
> example, no one will ask for MAY_APPEND and MAY_TAKE_OWNERSHIP at the
> same time?
>
> And adding that big "if (want & (MAY_APPEND | .. | MAY_SET_TIMES))" to
> let you skip over a bunch of checks in the common case?
>
> Does this help measurably? It seems complicated and, to the extent it
> makes assumptions about the callers, possibly fragile with respect to
> future changes.
>
Not the complete function. But I guess we can do the below change.
We still want to keep MAY_WRITE check separate, because VFS do add
MAY_WRITE request to different type of request other than write.
Andreas,
Do you see any issue in doing below ?
richacl_want_to_mask(int want)
{
unsigned int mask = 0;
if (want & MAY_READ)
mask |= ACE4_READ_DATA;
if (want & MAY_DELETE_SELF)
mask |= ACE4_DELETE;
if (want & MAY_TAKE_OWNERSHIP)
mask |= ACE4_WRITE_OWNER;
if (want & MAY_CHMOD)
mask |= ACE4_WRITE_ACL;
if (want & MAY_SET_TIMES)
mask |= ACE4_WRITE_ATTRIBUTES;
if (want & MAY_EXEC)
mask |= ACE4_EXECUTE;
/*
* differentiate MAY_WRITE from these request
*/
if (want & (MAY_APPEND |
MAY_CREATE_FILE | MAY_CREATE_DIR |
MAY_DELETE_CHILD)) {
if (want & MAY_APPEND)
mask |= ACE4_APPEND_DATA;
if (want & MAY_CREATE_FILE)
mask |= ACE4_ADD_FILE;
if (want & MAY_CREATE_DIR)
mask |= ACE4_ADD_SUBDIRECTORY;
if (want & MAY_DELETE_CHILD)
mask |= ACE4_DELETE_CHILD;
} else if (want & MAY_WRITE)
mask |= ACE4_WRITE_DATA;
return mask;
}
-aneesh
next prev parent reply other threads:[~2011-09-08 10:27 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-05 17:25 [PATCH -V6 00/26] New ACL format for better NFSv4 acl interoperability Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 01/26] vfs: Indicate that the permission functions take all the MAY_* flags Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 02/26] vfs: Add hex format for MAY_* flag values Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 03/26] vfs: Pass all mask flags down to iop->check_acl Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 04/26] vfs: Add a comment to inode_permission() Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 05/26] vfs: Add generic IS_ACL() test for acl support Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 06/26] vfs: Add IS_RICHACL() test for richacl support Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 07/26] vfs: Optimize out IS_RICHACL() if CONFIG_FS_RICHACL is not defined Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 08/26] vfs: Add new file and directory create permission flags Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 09/26] vfs: Add delete child and delete self " Aneesh Kumar K.V
2011-09-07 20:39 ` J. Bruce Fields
2011-09-08 9:30 ` Aneesh Kumar K.V
2011-09-08 20:07 ` J. Bruce Fields
2011-09-08 22:02 ` J. Bruce Fields
2011-09-09 5:19 ` Aneesh Kumar K.V
2011-09-09 5:25 ` Aneesh Kumar K.V
2011-09-09 12:02 ` J. Bruce Fields
2011-09-09 5:14 ` Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 10/26] vfs: Make the inode passed to inode_change_ok non-const Aneesh Kumar K.V
2011-09-07 20:43 ` J. Bruce Fields
2011-09-08 9:32 ` Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 11/26] vfs: Add permission flags for setting file attributes Aneesh Kumar K.V
2011-09-07 20:55 ` J. Bruce Fields
2011-09-08 9:36 ` Aneesh Kumar K.V
2011-09-08 20:08 ` J. Bruce Fields
2011-09-05 17:25 ` [PATCH -V6 12/26] vfs: Make acl_permission_check() work for richacls Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 13/26] richacl: In-memory representation and helper functions Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 14/26] richacl: Permission mapping functions Aneesh Kumar K.V
2011-09-07 21:24 ` J. Bruce Fields
2011-09-08 10:27 ` Aneesh Kumar K.V [this message]
2011-09-05 17:25 ` [PATCH -V6 15/26] richacl: Compute maximum file masks from an acl Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 16/26] richacl: Update the file masks in chmod() Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 17/26] richacl: Permission check algorithm Aneesh Kumar K.V
2011-09-07 21:50 ` J. Bruce Fields
2011-09-08 10:34 ` Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 18/26] richacl: Create-time inheritance Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 19/26] richacl: Check if an acl is equivalent to a file mode Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 20/26] richacl: Automatic Inheritance Aneesh Kumar K.V
2011-09-07 21:56 ` J. Bruce Fields
2011-09-05 17:25 ` [PATCH -V6 21/26] richacl: xattr mapping functions Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 22/26] vfs: Cache richacl in struct inode Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 23/26] vfs: Add richacl permission check Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 24/26] ext4: Use IS_POSIXACL() to check for POSIX ACL support Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 25/26] ext4: Implement rich acl for ext4 Aneesh Kumar K.V
2011-09-05 17:25 ` [PATCH -V6 26/26] ext4: Add temporary richacl mount option " Aneesh Kumar K.V
2011-09-05 22:42 ` [PATCH -V6 00/26] New ACL format for better NFSv4 acl interoperability Casey Schaufler
2011-09-08 0:46 ` Valdis.Kletnieks
2011-09-12 21:34 ` Casey Schaufler
2011-09-12 22:20 ` J. Bruce Fields
2011-09-12 22:38 ` Casey Schaufler
2011-09-12 22:43 ` J. Bruce Fields
2011-09-12 23:23 ` Casey Schaufler
2011-09-12 23:53 ` J. Bruce Fields
2011-09-13 4:41 ` Aneesh Kumar K.V
2011-09-13 18:12 ` Valdis.Kletnieks
2011-09-06 9:41 ` Steven Whitehouse
2011-09-06 13:58 ` Aneesh Kumar K.V
2011-09-07 20:18 ` J. Bruce Fields
2011-09-07 23:44 ` J. Bruce Fields
2011-09-08 10:40 ` Aneesh Kumar K.V
2011-09-09 10:02 ` [PATCH -V6 08/26] vfs: Add new file and directory create permission flags David Howells
2011-09-09 11:59 ` Aneesh Kumar K.V
2011-09-09 10:12 ` [PATCH -V6 09/26] vfs: Add delete child and delete self " David Howells
2011-09-09 11:55 ` Aneesh Kumar K.V
2011-09-09 10:36 ` [PATCH -V6 14/26] richacl: Permission mapping functions David Howells
2011-09-09 11:54 ` Aneesh Kumar K.V
2011-09-09 12:14 ` [PATCH -V6 18/26] richacl: Create-time inheritance David Howells
2011-09-09 12:37 ` [PATCH -V6 22/26] vfs: Cache richacl in struct inode David Howells
2011-09-09 12:45 ` [PATCH -V6 25/26] ext4: Implement rich acl for ext4 David Howells
2011-09-13 4:25 ` Aneesh Kumar K.V
2011-09-09 12:48 ` [PATCH -V6 00/26] New ACL format for better NFSv4 acl interoperability David Howells
2011-09-09 14:03 ` David Howells
2011-09-12 22:23 ` J. Bruce Fields
2011-09-12 22:27 ` David Howells
2011-09-13 5:07 ` Aneesh Kumar K.V
2011-09-21 7:30 ` Aneesh Kumar K.V
2011-09-21 19:45 ` J. Bruce Fields
2011-09-22 5:31 ` Aneesh Kumar K.V
2011-09-22 12:01 ` J. Bruce Fields
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=87aaaf5nxi.fsf@skywalker.in.ibm.com \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=agruen@kernel.org \
--cc=agruen@linbit.com \
--cc=akpm@linux-foundation.org \
--cc=bfields@fieldses.org \
--cc=dhowells@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).