Subject: Re: [nfsv4] New reclaim-related operations for v4.1

From: [email-masked]
Date: Fri, 3 Feb 2006 12:04:35 -0500 (EST)

Dave's writeup looks really good to me, but I thought I might suggest
that the authentication principal requirements be explicitly spelled
out for 4.1.

For the new RECLAIM Ops, would "same principal as used for SETCLIENTID"
be appropriate?

As Dave notes, there is nothing in RFC3530 that explicitly states what
authenticated principals should be allowed to do the OPEN and LOCK Ops
with Reclaim. It would be nice to see an explicit statement of what
is allowed. I see a couple of possibilities:
1 - Any principal that has appropriate access to the file.
2 - Same principal as was used for SETCLIENTID.

The only problem I can see w.r.t. #1 is if the access permissions on the
file have been reduced since the original OPEN/LOCK was granted, such that
the reclaim fails, because the client no longer has such an authenticated
principal. Should #2 be a possible fallback that servers can choose to
allow, if the server trusts the client's host based principal used for
SETCLIENTID?

Just a thought, rick

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

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 3 Feb 2006 18:28:03 -0600

> allow, if the server trusts the client's host based principal used for

So, this issue seems to point to the larger ambiguity in 4.0 that we have
discussed before about which principal should be used for subsequent
operation on a file.  The classic of principal used for OPEN should be
the same principal used for subsequenct, READ/WRITE/LOCK/CLOSE, etc.
and the denial of service that can occur from those scenarios.

This should be resolved and captured in the 4.1 specification.

As part of that, the issue of what principal should be used for recovery
operations must be captured as well.

My expectation would be that the same principal that was used for
the initial OPEN or LOCK should be used for the reclaim operations.
Generally, that principal should have the best opportunity to pass
the access checks for the file and therefore continue operation.
If that fails, the client is welcome to try the principal used for
SETCLIENTID but will likely do so only as a method to make  best
effort to continue data service to the client's applications.

Spencer