Subject: [nfsv4] pNFS authentication question...

From: Trond Myklebust <[email-masked]>
Date: Fri, 30 May 2008 11:13:15 -0700

In the 'files' pNFS model, how does the client 'prove' to the data
server that it is indeed the same client that was given a layout by the
MDS?

IOW, how does the DS identify a client, so that it can enforce the hard
requirement in section 12.5.1 that 'for a client to access a storage
device, a layout must be held by the client.' (btw, we can eliminate at
least one instance of 'client' in that sentence).

Cheers
  Trond

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

---

From: "Mike Eisler" <[email-masked]>
Date: Fri, 30 May 2008 11:30:57 -0700 (PDT)

> least one instance of 'client' in that sentence).

At minimum the client owner the client uses in the EXCHANGE_ID
requests to the MDS and DS needs to be the same. I believe the
spec mentions this.

In addition, the filehandles in the layout could be specific
to the client that sent LAYOUTGET.

If you want something stronger, you need RPCSEC_GSS.

The DS could set EXCHGID4_FLAG_BIND_PRINC_STATEID
in the EXCHANGE_ID reply. That way if RPCSEC_GSS is being used
to protect the file, only the principal that created
the stateid on the MDS can use the stateid with READ and WRITE
in requests to the DS.

If RPCSEC_GSS is not being used, then the client can of course
claim any client owner or AUTH_SYS uid in EXCHANGE_ID/READ/WRITE
requests, and there is nothing the DS can do about it.

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/

---

From: Jim Rees <[email-masked]>
Date: Fri, 30 May 2008 14:30:49 -0400

Trond Myklebust wrote:

  IOW, how does the DS identify a client, so that it can enforce the hard
  requirement in section 12.5.1 that 'for a client to access a storage
  device, a layout must be held by the client.'

The requirement as worded could be interpreted in two ways:

1. The SD must not allow a client to access its data unless the client has a
layout

2. A client must not try to access a SD unless it has a layout

So this is either a requirement for the client or the SD, or maybe both.
I'd like to see it re-worded to clarify.  I think you are using
interpretation 1 but the spec intends 2.

Note the next sentence, "If a storage device receives an I/O for a byte
range for which the client does not hold a layout, the storage device SHOULD
reject that I/O request."  "SHOULD", not "MUST."
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 30 May 2008 11:48:17 -0700

> reject that I/O request."  "SHOULD", not "MUST."

I don't see how that "SHOULD" changes my question. If the data server
doesn't have a means to identify the client, then it cannot _ever_
enforce the above requirement. IOW: the above sentence would be entirely
redundant.

...and there is also the fact that the same paragraph states that "The
requirement of NFSv4.1, that all user access rights MUST be obtained
through the appropriate open, lock, and access operations, is not
modified with the existence of layouts". Again that requires the data
server to identify the client as being one that holds the appropriate
state.

Cheers
  Trond

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 30 May 2008 12:00:20 -0700

> the stateid on the MDS can use the stateid with READ and WRITE

That sounds like what I'm looking for. How then does that work in the
presence of delegations? Is the delegation then irrevocably tied to the
principal used in the OPEN/WANT_DELEGATION/GET_DIR_DELEGATION call? I
ask 'cos I couldn't find any mention of that in draft 23...

Cheers
  Trond

---

From: "Mike Eisler" <[email-masked]>
Date: Fri, 30 May 2008 12:41:18 -0700 (PDT)

> ask 'cos I couldn't find any mention of that in draft 23...

The use of the spo_must_allow bitmap returned by
EXCHANGE_ID will avoid irrevocable ties.

For example the operation numbers for READ and WRITE could be set in
spo_must_allow, and then the machine or SSV principal could be used
in tandem with the delegation stateid as an argument to
READ or WRITE.