Subject: Re: [nfsv4] pNFS authentication question...

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

On Fri, May 30, 2008 11:30 am, Mike Eisler wrote:
>
> On Fri, May 30, 2008 11:13 am, Trond Myklebust wrote:
>> 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).
>
> 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.

I haven't found that mention, yet at least.

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

Related to this. The spec says:

   In NFSv4.1, the session ID in the SEQUENCE operation implies the
   client ID, which in turn might be used by the server to map the
   stateid to the right client/server pair.  However, when a data server
   is presented with a READ or WRITE operation with a stateid, because
   the stateid is associated with client ID on a metadata server, and
   because the session ID in the preceding SEQUENCE operation is tied to
   the client ID of the data server, the data server has no obvious way
   to determine the metadata server from the COMPOUND procedure, and
   thus has no way to validate the stateid.  One RECOMMENDED approach is
   for pNFS servers to encode metadata server routing and/or identity
   information in the data server filehandles as returned in the layout.

So if the issue is merely identity, the RECOMMENDED
approach is as described above.

If the issue is proper authentication, then use RPCSEC_GSS.

>
> 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/

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