On Mon, 1 Feb 2010 18:18:58 -0500, "J. Bruce Fields" <bfields@citi.umich.edu> wrote:
quoted text
> On Mon, Feb 01, 2010 at 11:04:50AM +0530, Aneesh Kumar K.V wrote:
> > Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> > ---
> >  fs/richacl_posix.c      |    7 +++++++
> >  include/linux/richacl.h |   10 ++++++----
> >  2 files changed, 13 insertions(+), 4 deletions(-)
> > 
> > diff --git a/fs/richacl_posix.c b/fs/richacl_posix.c
> > index 07db970..3cf2124 100644
> > --- a/fs/richacl_posix.c
> > +++ b/fs/richacl_posix.c
> > @@ -183,6 +183,13 @@ static void posix_to_richacl(struct posix_acl *pacl, int type,
> >  	acl->a_group_mask = richacl_mode_to_mask(mode >> 3);
> >  	acl->a_other_mask = richacl_mode_to_mask(mode);
> >  
> > +	/*
> > +	 * Mark that the acl as mapped from posix
> > +	 * This gives user space the chance to verify
> > +	 * whether the mapping was correct
> > +	 */
> 
> How would it use this information?  (And how could it be incorrect?)
> 

Incorrect in the sense of what user expected the mapping should be. 
This flag is later used by the userspace to indicate that the returned
richacl is a mapped richacl from Posix. The sysadmin should be able to
look at the flag and make sure the acl values are what he expected it
to be and the mapping code didn't map it wrongly.

NOTE: If the user belong to multiple groups, posix acl evaluation will
look at the group for which the requested access mask is allowed and
then apply the ACL_MASK values. That can be quiet confusing when we map to
richacl.

-aneesh
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html