Subject: [nfsv4] [LNFS] Server Side Copy

From: Thomas Haynes <[email-masked]>
Date: Fri, 20 May 2011 11:32:31 -0500

If the destination server uses NFSv4.2 to drive a copy, what are the implications
for LNFS?

Consider the client based copy:

cp /t/source/foo/name.tar.bz2 /t/dest/bar

then the client MUST have read permission to the file and write permission in
the directory. Further, it MUST have been able to traverse the respective namespaces.
And finally, with LNFS, it MUST pass MAC label checks at all points in the namespace.

When we instead do a SSC, things get a little more complicated.

With RPCSEC_GSSv3, the destination should be using 'tunneled' credentials and
subject labels from the client.

Without RPCSEC_GSSv3, the source MUST treat access by the destination for this
file as if it were coming from the credentials and subject label presented to it during
the COPY_NOTIFY.

The question is then how the source reacts to a access change:

1) Export change
2) DAC change
3) MAC label change

If the client was doing the copy, then the source could use Fencing operations
on the stateid to cut the client off.

Let S be the stateid the souce issued to the destination
during the OPEN (either via the URL or the CLAIM_FH).

With RPCSEC_GSSv3, the source will have access to the credentials
and subject label being used. It can fence off S when it detects a mismatch.

Without RPCSEC_GSSv3, the source will have to maintain a mapping
of S to the credentials and subject label it got from the client. When
the object label changes, it can fence off  if necessary.

Whes the source fences off S, then the destination is denied access, and
SHOULD use CB_COPY to inform the client that the SSC had been stopped.

Also, note that the destination may or may not have callbacks
registered with the source, so it might not react to a CB_LABEL_CHANGED.

Finally, it is possible for both the client and source to be LNFS
and the destination to not be.