Subject: [nfsv4] Why can LOCKU return NFS4ERR_ACCESS?

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 24 Nov 2004 10:37:46 -0800 (PST)

If you try to unlock a region for which you had no lock, then I don't
see why you would be checking for NFS4ERR_ACCESS.

If you try to unlock a region for which you had an outstanding lock,
then even if the access permissions changed on the export, I would
expect a client to be able to successfully be able to release that
lock.

I can't see why LOCKU needs NFS4ERR_ACCESS and CLOSE does not.

-- 
Tom Haynes, ex-cfb
[email-masked]

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Jim Rees <[email-masked]>
Date: Wed, 24 Nov 2004 15:43:34 -0500

Traditionally, EACCES means the mode bits denied the requested operation,
and EPERM means an ordinary user tried to do something reserved to the
superuser.  I don't think posix allows unlock to return either one.

---

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 24 Nov 2004 15:45:04 -0500

> But wouldn't that be NFS4ERR_PERM and not NFS4ERR_ACCESS?

Maybe.  I'm not all that clear on the distinction either.

> I.e., NFS4ERR_ACCESS states that the machine does not have
> permission to access the resource and 

That's not how I read the spec.

It says:

> NFS4ERR_ACCESS          Permission denied. The caller does not have the
>                         correct permission to perform the requested
>                         operation. Contrast this with NFS4ERR_PERM,
>                         which restricts itself to owner or privileged
>                         user permission failures.

You could read "the caller" as meanng the machine but I read it as
the machine/credential pair.

> NFS4ERR_PERM states
> that the machine does have permission to access the resource
> but the current user does not.

Spec says:

>   NFS4ERR_PERM          Not owner. The operation was not allowed
>                         because the caller is either not a privileged
>                         user (root) or not the owner of the target of
>                         the operation.

Which doesn't sound like what you said.  It clearly has to do with the
user but only if it is an issue of not being root or the owner.

Given ACL's it is hard to maintain this distinction.  If I try to set an
ACL on a file and I am not root, not the owner, and not mentioned in the
existing acl as someone who may set the acl, it is clear that I get an
error but which one?  How can I distinguish between failure to set it
because I am not root (PERM), because I am not the owner (PERM), and
because I am not mentioned in the acl (ACCESS).  In fact I fail
because of the conjunction of all three so maybe I should get error
15 (= 1+1+13)? :-)

>         NFS4ERR_PERM            = 1,    /* caller not privileged   */
>         NFS4ERR_ACCESS          = 13,   /* access denied           */
>
> I think some of the operations mix these up or just use NFS4ERR_ACCESS.

I think the distinction between machine-not-allowed and user-not-allowed 
would be clearer and more meaningful than what we have now.

> RENEW:

> That sounds like the caller is not priveleged, but it is based on
> the client and not the user, so NFS4ERR_ACCESS ends up being correct.

They say "the client" but the algorithm refers to the principal, i.e.
the user.

> WRITE:
>
> Can return NFS4ERR_ACCESS but not NFS4ERR_PERM.
>
> OPEN:
> 
> Can return either NFS4ERR_ACCESS or NFS4ERR_PERM.

Don't understand under what circumstances you would get PERM.

You could argue is the mode bits only allowed access (pardon
the expression) to the owner, than not being the owner of root
would cause EPERM to be returned, but then that would apply
to WRITE as well.

-----Original Message-----
From: Haynes, Tom 
Sent: Wednesday, November 24, 2004 3:14 PM
To: Noveck, Dave
Cc: Haynes, Tom; [email-masked]
Subject: Re: [nfsv4] Why can LOCKU return NFS4ERR_ACCESS?

But wouldn't that be NFS4ERR_PERM and not NFS4ERR_ACCESS?

I.e., NFS4ERR_ACCESS states that the machine does not have
permission to access the resource and NFS4ERR_PERM states
that the machine does have permission to access the resource
but the current user does not.

         NFS4ERR_PERM            = 1,    /* caller not privileged   */
         NFS4ERR_ACCESS          = 13,   /* access denied           */

I think some of the operations mix these up or just use NFS4ERR_ACCESS.

Some examples:

RENEW:

   The client that issues RENEW MUST choose the principal, RPC security
   flavor, and if applicable, GSS-API mechanism and service via one of
   the following algorithms:

   o  The client uses the same principal, RPC security flavor -- and if
      the flavor was RPCSEC_GSS -- the same mechanism and service that
      was used when the client id was established via
      SETCLIENTID_CONFIRM.

   o  The client uses any principal, RPC security flavor mechanism and
      service combination that currently has an OPEN file on the server.
      I.e.,  the same principal had a successful OPEN operation, the
      file is still open by that principal, and the flavor, mechanism,
      and service of RENEW match that of the previous OPEN.

   The server MUST reject a RENEW that does not use one the
   aforementioned algorithms, with the error NFS4ERR_ACCESS.

That sounds like the caller is not priveleged, but it is based on
the client and not the user, so NFS4ERR_ACCESS ends up being correct.

WRITE:

Can return NFS4ERR_ACCESS but not NFS4ERR_PERM.

OPEN:

Can return either NFS4ERR_ACCESS or NFS4ERR_PERM.

> Suppose the person doing the unlock is not the guy who did the
> lock.  Suppose he is just unlocking something that is yours, that
> he has business unlocking.  NFS4ERR_ACCESS seem reasonable in that
> case.  I'm not saying the server has to check that, but it could
> and I think it should be able to return the error.
> 
> I can't see any reason LOCKU and CLOSE would be different in this
> respect.
> 
> 
> 
> -----Original Message-----
> From: Haynes, Tom 
> Sent: Wednesday, November 24, 2004 1:38 PM
> To: [email-masked]
> Subject: [nfsv4] Why can LOCKU return NFS4ERR_ACCESS?
> 
> 

-- 
Tom Haynes, ex-cfb
[email-masked]

---

From: [email-masked]
Date: Wed, 24 Nov 2004 16:35:11 -0500 (EST)

and I could argue that "owner" would refer to lock_owner4 or open_owner4
for locks and opens, not the Principal that did the Open or Lock:-)

Personally, I think that authentication requirements for Close and LockU
are "underspecified" in the RFC and, as such, it will be risky for a server
to enforce requirements such as "same Principal that did the Lock/Open is
required to do the LockU/Close. Just MHO.

rick
ps: The RFC doesn't specify ACCESS or PERM as errors for Close. Was there
    an errata change that added these errors for Close?