linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).