[PATCH 11/16] nfsd4: return nfserr_wrongsec

Trond Myklebust trond.myklebust at fys.uio.no
Mon May 21 08:39:39 EDT 2007


On Mon, 2007-05-21 at 11:18 +0300, Benny Halevy wrote:
> J. Bruce Fields wrote:
> > On Fri, May 18, 2007 at 06:33:23PM -0400, Trond Myklebust wrote:
> >> On Fri, 2007-05-18 at 18:28 -0400, J. Bruce Fields wrote:
> >>>> On Fri, 2007-05-18 at 17:28 -0400, J. Bruce Fields wrote:
> >>>>> --- a/fs/nfsd/nfssvc.c
> >>>>> +++ b/fs/nfsd/nfssvc.c
> >>>>> @@ -492,6 +492,15 @@ out:
> >>>>>  	module_put_and_exit(0);
> >>>>>  }
> >>>>>  
> >>>>> +static __be32 map_new_errors(u32 vers, __be32 nfserr)
> >>>>> +{
> >>>>> +	if (nfserr == nfserr_jukebox && vers == 2)
> >>>>> +		return nfserr_dropit;
> >>>>> +	if (nfserr == nfserr_wrongsec && vers < 4)
> >>>>> +		return nfserr_perm;
> >>>>> +	return nfserr;
> >>>>> +}
> >>> Does that look sane?
> >> OK, but shouldn't it be mapped into EACCES? EPERM means that an
> >> operation failed because the caller is "either not a privileged user
> >> (root) or the owner of the target of the operation".
> > 
> > Yup, fixed.  I always have trouble getting those two straight.
> > 
> Some operations, e.g. SETATTR, are allowed to the owner of the file and to
> the super user.  If the caller isn't one of them EPERM should be returned.
> EACCES is returned when the caller does not have a permission to do the
> operation based on mode bits and or other cases which do not fall in the
> EPERM category.

If you are getting a WRONGSEC error, then you are basically not being
identified. You cannot be the owner of the file.

Trond



More information about the NFSv4 mailing list