On Mon, 1 Feb 2010 18:18:58 -0500, "J. Bruce Fields" <bfields@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> > > --- > > 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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
