linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com>
To: Brad Boyer <flar@allandria.com>
Cc: sandeen@redhat.com, adilger@sun.com, tytso@mit.edu,
	jlayton@redhat.com, bfields@citi.umich.edu, nfsv4@linux-nfs.org,
	samba@lists.samba.org, linux-fsdevel@vger.kernel.org,
	sfrench@us.ibm.com, ffilz@us.ibm.com, linux-ext4@vger.kernel.org,
	agruen@suse.de
Subject: Re: [PATCH 03/23] vfs: rich ACL in-memory representation and manipulation
Date: Mon, 01 Feb 2010 23:32:59 +0530	[thread overview]
Message-ID: <87y6jczve4.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <20100201072852.GA17309@cynthia.pants.nu>

On Sun, 31 Jan 2010 23:28:52 -0800, Brad Boyer <flar@allandria.com> wrote:
> 
> I have one suggestion about this part of the code.
> 
> On Mon, Feb 01, 2010 at 11:04:45AM +0530, Aneesh Kumar K.V wrote:
> 
> <snip>
> 
> > +/*
> > + * ACL entries that have ACE4_SPECIAL_WHO set in ace->e_flags use the
> > + * pointer values of these constants in ace->u.e_who to avoid massive
> > + * amounts of string comparisons.
> > + */
> > +
> > +const char richace_owner_who[]	  = "OWNER@";
> > +EXPORT_SYMBOL_GPL(richace_owner_who);
> > +const char richace_group_who[]	  = "GROUP@";
> > +EXPORT_SYMBOL_GPL(richace_group_who);
> > +const char richace_everyone_who[] = "EVERYONE@";
> > +EXPORT_SYMBOL_GPL(richace_everyone_who);
> 
> <snip>
> 
> > +/*
> > + * richace_is_same_who  -  do both acl entries refer to the same identifier?
> > + */
> > +int
> > +richace_is_same_who(const struct richace *a, const struct richace *b)
> > +{
> > +#define WHO_FLAGS (ACE4_SPECIAL_WHO | ACE4_IDENTIFIER_GROUP)
> > +	if ((a->e_flags & WHO_FLAGS) != (b->e_flags & WHO_FLAGS))
> > +		return 0;
> > +	if (a->e_flags & ACE4_SPECIAL_WHO)
> > +		return a->u.e_who == b->u.e_who;
> > +	else
> > +		return a->u.e_id == b->u.e_id;
> > +#undef WHO_FLAGS
> > +}
> > +
> > +/**
> > + * richacl_set_who  -  set a special who value
> > + * @ace:	acl entry
> > + * @who:	who value to use
> > + */
> > +int
> > +richace_set_who(struct richace *ace, const char *who)
> > +{
> > +	if (!strcmp(who, richace_owner_who))
> > +		who = richace_owner_who;
> > +	else if (!strcmp(who, richace_group_who))
> > +		who = richace_group_who;
> > +	else if (!strcmp(who, richace_everyone_who))
> > +		who = richace_everyone_who;
> > +	else
> > +		return -EINVAL;
> > +
> > +	ace->u.e_who = who;
> > +	ace->e_flags |= ACE4_SPECIAL_WHO;
> > +	ace->e_flags &= ~ACE4_IDENTIFIER_GROUP;
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(richace_set_who);
> > +
> > +/**
> > + * richacl_allowed_to_who  -  mask flags allowed to a specific who value
> > + *
> > + * Computes the mask values allowed to a specific who value, taking
> > + * EVERYONE@ entries into account.
> > + */
> > +static unsigned int
> > +richacl_allowed_to_who(struct richacl *acl, struct richace *who)
> > +{
> > +	struct richace *ace;
> > +	unsigned int allowed = 0;
> > +
> > +	richacl_for_each_entry_reverse(ace, acl) {
> > +		if (richace_is_inherit_only(ace))
> > +			continue;
> > +		if (richace_is_same_who(ace, who) ||
> > +		    richace_is_everyone(ace)) {
> > +			if (richace_is_allow(ace))
> > +				allowed |= ace->e_mask;
> > +			else if (richace_is_deny(ace))
> > +				allowed &= ~ace->e_mask;
> > +		}
> > +	}
> > +	return allowed;
> > +}
> 
> <snip>
> 
> > +struct richace {
> > +	unsigned short	e_type;
> > +	unsigned short	e_flags;
> > +	unsigned int	e_mask;
> > +	union {
> > +		unsigned int	e_id;
> > +		const char	*e_who;
> > +	} u;
> > +};
> 
> <snip>
> 
> > +/* Special e_who identifiers: we use these pointer values in comparisons
> > +   instead of strcmp for efficiency. */
> > +
> > +extern const char richace_owner_who[];
> > +extern const char richace_group_who[];
> > +extern const char richace_everyone_who[];
> > +
> > +static inline int
> > +richace_is_owner(const struct richace *ace)
> > +{
> > +	return (ace->e_flags & ACE4_SPECIAL_WHO) &&
> > +	       ace->u.e_who == richace_owner_who;
> > +}
> > +
> > +static inline int
> > +richace_is_group(const struct richace *ace)
> > +{
> > +	return (ace->e_flags & ACE4_SPECIAL_WHO) &&
> > +	       ace->u.e_who == richace_group_who;
> > +}
> > +
> > +static inline int
> > +richace_is_everyone(const struct richace *ace)
> > +{
> > +	return (ace->e_flags & ACE4_SPECIAL_WHO) &&
> > +	       ace->u.e_who == richace_everyone_who;
> > +}
> > +
> > +static inline int
> > +richace_is_unix_id(const struct richace *ace)
> > +{
> > +	return !(ace->e_flags & ACE4_SPECIAL_WHO);
> > +}
> 
> Wouldn't it make more sense to just store some small numeric value
> in ace->u.e_who rather than a pointer? It seems to me that the
> savings of storing and comparing an integer type would more than
> make up for the slight overhead of needing to lookup a pointer
> in the places where the code must handle an external representation.
> I know there is really only a difference on 64-bit systems, but my
> impression has been that most people are going that way. In particular,
> the struct richace would go to 12 bytes with 4-byte alignment from
> 16 bytes with 8-byte alignment on an architecture with 8-byte pointers.
> Plus doing an integer instead of a pointer should eliminate the need
> to export the constant pointer values. Even in 32-bit, there are a
> few odd architectures (like m68k) that have separate address and
> data registers, so using an integer may have some benefits there
> due to the fact that the instruction set treats them differently.
> 
> I know you mentioned that you didn't originally write this code, but
> it seems a logical change to me.

I guess id mapping needs more work in the patch. I would really like
to hear from both NFS and Samba people in how they would like the
id details to be stored. If we can't map an incoming user@domain
request on nfs, I guess we definitely don't want to store the acl with
'nobody' id

-aneesh

  reply	other threads:[~2010-02-01 18:02 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-01  5:34 [RFC PATCH] New ACL format for better NFSv4 acl interoperability Aneesh Kumar K.V
2010-02-01  5:34 ` [PATCH 01/23] vfs: VFS hooks for per-filesystem permission models Aneesh Kumar K.V
2010-02-01  5:34 ` [PATCH 02/23] vfs: Check for create permission during rename Aneesh Kumar K.V
2010-02-01  5:34 ` [PATCH 03/23] vfs: rich ACL in-memory representation and manipulation Aneesh Kumar K.V
2010-02-01  7:28   ` Brad Boyer
2010-02-01 18:02     ` Aneesh Kumar K. V [this message]
2010-02-01 23:06       ` J. Bruce Fields
2010-02-01 23:21   ` J. Bruce Fields
2010-02-01  5:34 ` [PATCH 04/23] richacl: Add write retention and retention hold access mask Aneesh Kumar K.V
2010-02-01  5:34 ` [PATCH 05/23] ext4: Implement rich acl for ext4 Aneesh Kumar K.V
2010-02-01  5:34 ` [PATCH 06/23] vfs: Implement those parts of Automatic Inheritance (AI) which are safe under POSIX Aneesh Kumar K.V
2010-02-01  5:34 ` [PATCH 07/23] vfs: Add Posix acl to rich acl mapping helpers Aneesh Kumar K.V
2010-02-01 23:18   ` J. Bruce Fields
2010-02-02  5:22     ` Aneesh Kumar K. V
2010-02-01  5:34 ` [PATCH 08/23] vfs: Add a flag to denote posix mapped richacl Aneesh Kumar K.V
2010-02-01 23:18   ` J. Bruce Fields
2010-02-02  5:33     ` Aneesh Kumar K. V
2010-02-02 15:18       ` J. Bruce Fields
2010-02-01  5:34 ` [PATCH 09/23] ext4: Add posix acl to rich acl mapping Aneesh Kumar K.V
2010-02-01  5:34 ` [PATCH 10/23] richacl: Add separate file and dir acl masks Aneesh Kumar K.V
2010-02-01  5:34 ` [PATCH 11/23] richacl: Move the xattr representation to little-endian format Aneesh Kumar K.V
2010-02-01 23:34   ` J. Bruce Fields
2010-02-02  5:35     ` Aneesh Kumar K. V
2010-02-01  5:34 ` [PATCH 12/23] richacl: Use directory specific mask values for operation on directories Aneesh Kumar K.V
2010-02-01  5:34 ` [PATCH 13/23] richacl: Follow nfs4 acl delete definition Aneesh Kumar K.V
2010-02-01  5:34 ` [PATCH 14/23] richacl: Disable automatic inheritance with posix mapped acls Aneesh Kumar K.V
2010-02-01  5:34 ` [PATCH 15/23] richacl: Delete posix acl if present on richacl set Aneesh Kumar K.V
2010-02-01  5:34 ` [PATCH 16/23] ext4: Update richacl incompat flag value Aneesh Kumar K.V
2010-02-01 23:41   ` J. Bruce Fields
2010-02-01  5:34 ` [PATCH 17/23] vfs: Add new MS_ACL and MS_RICHACL flag Aneesh Kumar K.V
2010-02-01  5:35 ` [PATCH 18/23] richacl: Add helper function for creating richacl from mode values Aneesh Kumar K.V
2010-02-01  5:35 ` [PATCH 19/23] fs: Use the correct MS_*ACL flags in file system code Aneesh Kumar K.V
2010-02-01  5:35 ` [PATCH 20/23] nfsd: Apply NFSv4acl to posix acl mapping only if MS_POSIXACL is set Aneesh Kumar K.V
2010-02-01  5:35 ` [PATCH 21/23] richacl: Add helpers for NFSv4 acl to richacl conversion Aneesh Kumar K.V
2010-02-01  5:35 ` [PATCH 22/23] nfsd: Add support for reading rich acl from file system Aneesh Kumar K.V
2010-02-01  5:35 ` [PATCH 23/23] nfsd: Add support for saving richacl Aneesh Kumar K.V

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=87y6jczve4.fsf@linux.vnet.ibm.com \
    --to=aneesh.kumar@linux.vnet.ibm.com \
    --cc=adilger@sun.com \
    --cc=agruen@suse.de \
    --cc=bfields@citi.umich.edu \
    --cc=ffilz@us.ibm.com \
    --cc=flar@allandria.com \
    --cc=jlayton@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=nfsv4@linux-nfs.org \
    --cc=samba@lists.samba.org \
    --cc=sandeen@redhat.com \
    --cc=sfrench@us.ibm.com \
    --cc=tytso@mit.edu \
    /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).