On Tue, Feb 02, 2010 at 11:03:09AM +0530, Aneesh Kumar K. V wrote:
quoted text
> On Mon, 1 Feb 2010 18:18:58 -0500, "J. Bruce Fields" <bfields@citi.umich.edu> wrote:
> > 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.

It's not going to map wrongly--if it does, there's a bug, and we should
just fix the bug.

It's not reasonable to expect sysadmins to manually check mapped ACL's
to look for bugs in our mapping algorithm.

--b.

quoted text
> 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