Subject: Re: [nfsv4] NFSv4.2 draft inter server copy correction

From: "Adamson, Andy" <[email-masked]>
Date: Mon, 2 Mar 2015 14:47:09 +0000

> On Feb 28, 2015, at 5:56 AM, David Noveck <[email-masked]> wrote:
> 
> > I don’t think we want to do an OPEN  from the destination server, because we already have an open stateid, and doing an OPEN from the destination 
> > server will conflict with: [4.4.1]
> 
> True but the way 4.4.1 is written, it is not clear that where will always be an OPEN e.g. "may need", "can achieve", "might be desired”.

The whole point of passing the source stateid and file handle is to obviate the need for an OPEN from the destination server, and totally avoid the issues of a share or byterange lock on the OPEN’s from the client.  If the destination server is implemented to use the compound with the OPEN in Section 4.10.1.2, then when the OPENs issued by the client do have a conflicting share or byte-range lock, the copy will fail. Since there is no reason for the OPEN/GETFH, I say remove it.

—>Andy

> On Fri, Feb 27, 2015 at 2:50 PM, Adamson, Andy <[email-masked]> wrote:
> Hi Tom
> 
> in 4.10.1.2.  Inter-Server Copy via ONC RPC without RPCSEC_GSS:
> 
>    The client will then send these URLs to the destination server in the
>    COPY operation.  Suppose that the 192.0.2.0/24 network is a high
>    speed network and the destination server decides to transfer the file
>    over this network.  If the destination contacts the source server
>    from 192.0.2.56 over this network using NFSv4.1, it does the
>    following:
> 
>    COMPOUND  { PUTROOTFH, LOOKUP "_COPY" ; LOOKUP
>       "FvhH1OKbu8VrxvV1erdjvR7N" ; LOOKUP "203.0.113.56"; LOOKUP "_FH" ;
>       OPEN "0x12345" ; GETFH }
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> I don’t think we want to do an OPEN  from the destination server, because we already have an open stateid, and doing an OPEN from the destination server will conflict with:
> 
> 4.4.1.  Locking the Files
> 
> 
>    Both the source and destination file may need to be locked to protect
>    the content during the copy operations.  A client can achieve this by
>    a combination of OPEN and LOCK operations.  I.e., either share or
>    byte range locks might be desired.
> 
> 
> I also think the GETFH is not needed, as the COPY compound has the SAVE_FH which provides the FH of the file to READ.
> 
> —>Andy
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: Tom Haynes <[email-masked]>
Date: Tue, 3 Mar 2015 09:56:37 -0800

> On Mar 2, 2015, at 6:47 AM, Adamson, Andy <[email-masked]> wrote:
> 
> 

This section details how the destination can authenticate.

So if the destination server uses the FH directly, then the random number is useless since it will never be called.

And, the source is supposed to understand that it must not fail the copy for the destination opening the file even in the
presence of a conflicting share and/or byte-range lock. You can ask how the client is supposed to differentiate between
the destination opening the file for some other user versus this COPY and the answer is by processing the path
given by the URL.

---

From: Andy Adamson <[email-masked]>
Date: Tue, 3 Mar 2015 13:38:13 -0500

> This section details how the destination can authenticate.

OK. Some questions. From the spec:

     ^^^^^^^^^^^^^^
(Why is a 203.0.113 address being used over the 192.0.2. network?)

      OPEN "0x12345" ; GETFH }

If you are doing an OPEN CLAIM_FH, why do you need a GETFH?

I'm guessing that the idea here is that the OPEN by file handle in the
URL using the file handle from the SAVE_FH in the COPY compound (e.g.
the file handle from the OPEN to the source server by the client) in
this URL will return an "authenticated file handle" in GETFH that the
destination server can then use for the copy READ and this makes it
'authenticated'? I'm guessing, because there is no mention of this in
the spec. Also not mentioned is which stateid a READ from the
destination server will use. The ca_src_stateid or the stateid
returned by the OPEN in the above URL?

   Provided that the random number is unpredictable and has been kept
   secret by the parties involved, the source server will therefore know
   that these NFSv4.x operations are being issued by the destination
   server identified in the COPY_NOTIFY.  This random number technique
   only provides initial authentication of the destination server, and
   cannot defend against man-in-the-middle attacks after authentication
   or an eavesdropper that observes the random number on the wire.
   Other secure communication techniques (e.g., IPsec) are necessary to
   block these attacks.

> So if the destination server uses the FH directly, then the random number is useless since it will never be called.

Why not get rid of the OPEN/GETFH in the URL and replace it with the
PUTFH"0x12345"/READ "ca_src_stateid' that you actually want? Then
authentication occurs as the random number is presented, then there is
no OPEN for the source server to treat in a special way.

> presence of a conflicting share and/or byte-range lock.
> You can ask how the client is supposed to differentiate between

---

From: Tom Haynes <[email-masked]>
Date: Tue, 3 Mar 2015 11:11:37 -0800

> On Mar 3, 2015, at 10:38 AM, Andy Adamson <[email-masked]> wrote:
> 
> <[email-masked] <mailto:[email-masked]>> wrote:
>> 

This was a question Olga asked last week?  

In a multi-homed
   environment, the destination server might not contact the source
   server from the same network address specified by the client in the
   COPY_NOTIFY.  This can be overcome using the procedure described
   below.

..

Look at the available URLs:

      nfs://203.0.113.18//_COPY/FvhH1OKbu8VrxvV1erdjvR7N/203.0.113.56/
      _FH/0x12345

      nfs://192.0.2.18//_COPY/FvhH1OKbu8VrxvV1erdjvR7N/203.0.113.56/_FH/
      0x12345

Each of the components is part of the tuple which describes allowed access.

By presenting each of them within the compound, the destination is
authenticating itself to the source.

> no OPEN for the source server to treat in a special way.

I think the confusion here is that the suggested approach is just one
implementation approach that could be taken, especially if someone
wants to use the pseudo-random number mumbo-jumbo to fake
themselves into thinking there has been no man-in-the-middle attack.

Another perfectly valid approach is to throw Section 4.10.1.2. out and
just use OPEN CLAIM_FH. If the source doesn’t allow access, then
try getting a FH with the mumbo-jumbo.

>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/nfsv4 <https://www.ietf.org/mailman/listinfo/nfsv4>

---

From: Chuck Lever <[email-masked]>
Date: Tue, 3 Mar 2015 14:20:57 -0500

>       nfs://192.0.2.18//_COPY/FvhH1OKbu8VrxvV1erdjvR7N/203.0.113.56/_FH/

NFS URIs are defined in the FedFS NSDB protocol doc. Do these
URLs conform to that specification, or does NFSv4.2 construct
NFS URLs differently?

See

https://datatracker.ietf.org/doc/draft-ietf-nfsv4-federated-fs-protocol/?include_text=1

Section 2.8.1.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

---

From: Tom Haynes <[email-masked]>
Date: Tue, 3 Mar 2015 13:34:17 -0800

> On Mar 3, 2015, at 11:20 AM, Chuck Lever <[email-masked]> wrote:
> 
> 
> On Mar 3, 2015, at 2:11 PM, Tom Haynes <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> 

These are not NFS URLs, they are COPY URLs.

> 
> See
> 
> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-federated-fs-protocol/?include_text=1 <https://datatracker.ietf.org/doc/draft-ietf-nfsv4-federated-fs-protocol/?include_text=1>
> 
> Section 2.8.1.
>

---

From: Chuck Lever <[email-masked]>
Date: Tue, 3 Mar 2015 17:15:25 -0500

> These are not NFS URLs, they are COPY URLs.

In other words, the “nfs” scheme name means something different when
used to mount a public NFS server or store a FileSet Location than it
does when used in a COPY URL?

Section 3.1 of RFC 3986 says:
 
   Each URI begins with a scheme name that refers to a specification for
   assigning identifiers within that scheme.  As such, the URI syntax is
   a federated and extensible naming system wherein each scheme’s
   specification may further restrict the syntax and semantics of
   identifiers using that scheme.

The specification for the path component of an nfs:// URI is in
section 2.8.1.2 of the FedFS NSDB protocol draft. The meaning of the
particular URI that you pass in your examples is a file whose path
name is:

  /_COPY/FvhH1OKbu8VrxvV1erdjvR7N/203.0.113.56/_FH/0x12345

and is accessed via NFSv4.

I may be wrong about this, but I don’t think you can change the
interpretation of well-known URI schemes. Does anyone here know
for sure?

You _can_ create new URI schemes and specify their naming system in
the minor version 2 draft. That might be a cleaner approach to
accessing the source server’s FH space.