Subject: [nfsv4] [3530bis] Item #7

From: Thomas Haynes <[email-masked]>
Date: Mon, 14 Feb 2011 15:12:05 -0600

We have a very terse description here:

7) We need SECINFO workarounds on LOOKUPP and PUTROOTFH.

Action:
Owner:
State: Ask for clarification
Target:

Anyone want to own up to submitting the issue and explain what is meant here?

Thanks

---

From: Trond Myklebust <[email-masked]>
Date: Mon, 14 Feb 2011 16:33:24 -0500

> Anyone want to own up to submitting the issue and explain what is meant here?

I believe that is one of mine.

The issue is what to do if the server replies with NFS4ERR_WRONGSEC to
either LOOKUPP, or PUTROOTFH or to one of the subsequent operations in a
COMPOUND containing either one of those two operations.

None of these cases allow you to use SECINFO (a problem that triggered
the invention of SECINFO_NONAME in NFSv4.1). The workaround in NFSv4 is
probably to have the client just to attempt all known security flavours
until it finds one that works, but we really should document this in
RFC3530bis.

Cheers
  Trond

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
[email-masked]
www.netapp.com

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 14 Feb 2011 16:02:53 -0600

Thanks for un-tersing this for me!

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 14 Feb 2011 16:15:05 -0600

So the spec partially handles this:

            For PUTROOTFH and PUTPUBFH, the client will be unable
            to use the SECINFO operation since SECINFO requires a
            current filehandle and none exist for these two operations.
            Therefore, the client must iterate through the security
            triples available at the client and reattempt the PUTROOTFH
            or PUTPUBFH operation. In the unfortunate event none
            of the MANDATORY security triples are supported by the
            client and server, the client SHOULD try using others that
            support integrity. Failing that, the client can try using
            AUTH_NONE, but because such forms lack integrity checks,
            this puts the client at risk.  Nonetheless, the server
            SHOULD allow the client to use whatever security form the
            client requests and the server supports, since the risks
            of doing so are on the client.

See Section 15.33.5 on page 272.

It looks like I just need to add LOOKUPP to the section. Note that
this includes touching up:

   As mentioned, the server's security policies will determine when a
   client request receives NFS4ERR_WRONGSEC.  The operations which may
   receive this error are: LINK, LOOKUP, OPEN, PUTFH, PUTPUBFH,
   PUTROOTFH, RESTOREFH, RENAME, and indirectly READDIR.  ...