Subject: RE: server implementation question

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 5 Jun 2001 07:45:54 -0700

Mike Eisler wrote:
> I agree. However, like David Robinson, I can imagine servers
> that choke when the different credentials are used for
> the same OPEN "context.". 

I can imagine such servers too.  But the question is "If such 
servers exist, are they broken?".

The possible answers to that are in order of (my) decreasing
preference, "yes", "no", and "not exactly".  

> Therefore, I propose that the specification 
> should state that servers SHOULD NOT uses reject subsequent IO
> requests with different creds, and clients SHOULD NOT send IO requests
> with different creds.

So the server which does reject subsequent IO's with different creds
is not exactly broken but it's not doing what it should do.

Similarly, the client which issues IO with different creds is not
exactly broken but it's also not doing what it should do.

So if you have a server which does not honor the SHOULD NOT working 
with a client which does honor its SHOULD NOT, it will work and you
will not aware of any problem with the server.

And if you have a client which does not honor its SHOULD NOT working
with a server which does honor its SHOULD NOT, it will also work
and you will not be aware of any problem with the client.

So you now have a server and a client which interoperates fine 
with all of the reference implementations (I assume, perhaps naively, 
that none of them are going to do what they SHOULD NOT do).

Now if the SHOULD-NOT-server and SHOULD-NOT-client try to inter-
operate, they can't and they both say that they are compliant
and the other guy is broken and they are both sort of right.  The
problem is that the user would say that NFS-v4 interoperability 
is a minefield and he would be right too.  

> As you pointed out,
> the latter is actually not difficult to achieve, even given David 
> Robinson's setuid example.

It's not difficult to achieve if that is the semantics you want.
As long as we are being imaginitive, I can imagine systems hich 
want the semantics that the change in identity has immediate 
effect, so that saving open creds is not what the user wants.
I don't know if such systems exist but if they do, they could
be supported by V2/V3.

I think the protocol can either accommodate the hypothetical 
servers that cannot deal with different credentials on IO 
within an open file or the hypothetical clients that need to
issue IO with different credentials on the same open file.
I don't think we can accommodate both.

-----Original Message-----
From: Mike Eisler [mailto:[email-masked]]
Sent: Monday, June 04, 2001 3:01 PM
To: [email-masked]
Subject: RE: server implementation question

"Noveck, Dave" <[email-masked]> writes:

> David Robinson wrote:
> > So should the server accept or reject a request which has a different 
> > principal than a previous request?  I think this is a server
> > implementation
> > question without one definative answer. 
> 
> I think there should be a definitve answer to this question and
> it should not be left as an implementation choice.  I don't
> think there is any difficulty that different types of servers
> would encounter with a common answer that would force us to 
> allow different answers and increase interoperabiltiy difficulties.
> 
> There are three possible answers:
> 
>       (a) The server uses the credentials he gets on each request,
>           period.
> 
>       (b) The server uses the credentials he got on the open (regular
>           or reclaim).
> 
>       (c) The server insists that the credentials on the open and 
>           the request containing the IO operation are the same and 
>           rejects the operation if not.
> 
> I think we need to pick one.  Allowing multiple answers is going to 
> be an interoperability nightmare.
> 
> I think the proper answer is (a).  Stateid and credentials are separate.
> The server should not insist that subsequent IO requests use the 
> same credentials or second-guess the client and use credentials on 
> an IO request other than those actually presented on that request.

I agree. However, like David Robinson, I can imagine servers
that choke when the different credentials are used for
the same OPEN "context.". Therefore, I propose that the specification 
should state that servers SHOULD NOT uses reject subsequent IO
requests with different creds, and clients SHOULD NOT send IO requests
with different creds. As you pointed out,
the latter is actually not difficult to achieve, even given David 
Robinson's setuid example. 

	-mre

---

From: Mike Eisler <[email-masked]>
Date: Tue, 05 Jun 2001 08:58:34 -0700

> and you will not be aware of any problem with the client.

It comes down to the meaning of SHOULD NOT in IETF-speak:
"there may exist valid reasons in particular circumstances when the
 particular behavior is acceptable or even useful, but the full
 implications should be understood and the case carefully weighed
 before implementing any behavior described with this label."

> that none of them are going to do what they SHOULD NOT do).

With similar naivete, I presume that in order to achieve Draft Standard,
all the interoperating implementations
will conform to the SHOULD NOTs.

> is a minefield and he would be right too.

Buyer Beware. On the other hand, if we change SHOULD NOT to
MUST NOT, then another user might decry the injustice that
he cannot choose to have a crippled NFSv4 implementation on
his particular client or server operating environment. The
ultimate in non-interoperability. 

Practically speaking though, I doubt it makes much
difference. Toggle SHOULD NOT to MUST
NOT, and and there will still be fringe
NFSv4 implementations. The question is what is
the value of giving the user a scapegoat via
the use of MUST NOT, versus the value of NFSv4
being perceived as a Big Tent that allows all
comers under most circumstances.

	-mre