On Fri, 17 Dec 2010 12:10:38 +0530, "Aneesh Kumar K. V" <aneesh.kumar@xxxxxxxxxxxxxxxxxx> wrote:
> On Thu, 16 Dec 2010 12:49:52 -0500, Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> wrote:
> > On Thu, 2010-12-16 at 22:45 +0530, Aneesh Kumar K. V wrote:
> > > Any update on this ?
> > >
> > > -aneesh
> > >
> > > On Thu, 9 Dec 2010 17:05:14 +0530, "Aneesh Kumar K.V" <aneesh.kumar@xxxxxxxxxxxxxxxxxx> wrote:
> > > > We want to skip VFS applying mode for NFS. So set MS_POSIXACL always
> > > > and selectively use umask. Ideally we would want to use umask only
> > > > when we don't have inheritable ACEs set. But NFS currently don't
> > > > allow to send umask to the server. So this is best what we can do
> > > > and this is consistent with NFSv3
> > > >
> > > > Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@xxxxxxxxxxxxxxxxxx>
> > > > ---
> > > > fs/nfs/dir.c | 3 +--
> > > > fs/nfs/nfs4proc.c | 5 +++++
> > > > fs/nfs/super.c | 10 ++++++++++
> > > > 3 files changed, 16 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/fs/nfs/super.c b/fs/nfs/super.c
> > > > index 3c04504..e57e670 100644
> > > > --- a/fs/nfs/super.c
> > > > +++ b/fs/nfs/super.c
> > > > @@ -2508,6 +2513,11 @@ static void nfs4_fill_super(struct super_block *sb)
> > > > {
> > > > sb->s_time_gran = 1;
> > > > sb->s_op = &nfs4_sops;
> > > > + /*
> > > > + * The VFS shouldn't apply the umask to mode bits. We will do
> > > > + * so ourselves when necessary.
> > > > + */
> > > > + sb->s_flags |= MS_POSIXACL;
> > > > nfs_initialise_sb(sb);
> > > > }
> >
> > Won't this end up possibly turning on ACL checking in
> > acl_permission_check()?
>
> acl_permission_check get called only when we don't define an
> inode->permission callback. In case of nfs client we do define
> nfs_permission callback. In case we don't define a access NFS proto
> callback we are still ok because in that case we want mode based
> validation and we do pass check_acl as NULL
>
Can we get this upstream ?
-aneesh
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
