[08/23] vfs: Add a flag to denote posix mapped richacl

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

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

--b.

> +	acl->a_flags |= ACL4_POSIX_MAPPED;
> +
>  	return;
>  }
>  
> diff --git a/include/linux/richacl.h b/include/linux/richacl.h
> index b08fdf1..41d93d8 100644
> --- a/include/linux/richacl.h
> +++ b/include/linux/richacl.h
> @@ -36,12 +36,14 @@ struct richacl {
>  #define ACL4_AUTO_INHERIT		0x01
>  #define ACL4_PROTECTED			0x02
>  #define ACL4_DEFAULTED			0x04
> +#define ACL4_POSIX_MAPPED		0x10
>  #define ACL4_WRITE_THROUGH		0x40
>  
> -#define ACL4_VALID_FLAGS ( \
> -	ACL4_AUTO_INHERIT | \
> -	ACL4_PROTECTED | \
> -	ACL4_DEFAULTED | \
> +#define ACL4_VALID_FLAGS (	\
> +	ACL4_AUTO_INHERIT |	\
> +	ACL4_PROTECTED |	\
> +	ACL4_DEFAULTED |	\
> +	ACL4_POSIX_MAPPED |	\
>  	ACL4_WRITE_THROUGH)
>  
>  /* e_type values */
> -- 
> 1.7.0.rc0.48.gdace5
> 
--
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

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.

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

On Tue, Feb 02, 2010 at 11:03:09AM +0530, Aneesh Kumar K. V wrote:
> 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.

> 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