Subject: RE: [nfsv4] Why can LOCKU return NFS4ERR_ACCESS?

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 24 Nov 2004 14:56:58 -0500

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 why LOCKU needs NFS4ERR_ACCESS and CLOSE does not.

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?

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

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

---

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 24 Nov 2004 12:14:26 -0800 (PST)

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.

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