Subject: RE: server implementation question

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 4 Jun 2001 09:05:11 -0700

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.

First, I think this is the answer in the current spec, although
it needs to be clarified.  Kendrick is right that the spec 
is silent on the matter, but I would argue that that silence
speaks volumes.  The two concepts (i.e credentials and stateid's)
are extensively discussed and nowhere is it suggested that there
is a connection between them.  The strong implication is that
they are not connected and that the server implements them 
separately.

It is the case that UNIX clients are implemented so that the
credentials are saved at open and then used for subsequent IO 
requests but we know how to do this (for V2/V3) so there is
no benefit to the clients in a different model.  In (c), he
still has to save them and present them on each request.  Even
in (b) the client still has to save the credentials to be used 
on open-reclaim.  So there is no benefit to the client, even
though the server would have to maintain extra state for each 
open  file.

Having the server keep credentials and stateid's separate can
support UNIX client semantics but also support clients which
do this differently (i.e. by making changes in identity even
apply to subsequent IO on open files).  UNIX clients can
save the credentials at open time and we have the code do 
that.  If servers implemented (b) or (c) there would
be no way to support those other clients.  Even if such 
clients don't currently exist, there doesn't seem to be
any need to go to a model in which stateid and credentials
are linked, especially at this point, and especially given
that this is an area with all kinds of security issues.
In fact, it consists of nothing but security issues :-(

Given the fact that the stateid's are not secure (unless
you are using integity or privacy) means that (b) without
integrity or privacy has a gaping security hole.

Choosing (c) means that you cannot issue a request that
does IO on multiple open files which it might reasonably 
want to do, even if the client code had available credentials 
that would allow it to do each of those operations.  That 
would be a new restriction on clients that might prevent 
some interesting uses of compound.  The spec right now
says the server needs to save the principal that did a
setclientid so that it can verify future setclientid's,
so it does specify such restrictions when appropriate.
It currently doesn't specify such a restriction between
open and IO or among IO operations within a compound.
So the fact that no restriction is specified indicates
to me that there is no such restriction and that it is
OK for clients to change principals on an exsting open
file or do IO to multiple open files within a signle 
requests, if otherwise allowed. 

----Original Message-----
From: David Robinson [mailto:[email-masked]]
Sent: Sunday, June 03, 2001 11:16 PM
To: Kendrick M. Smith
Cc: [email-masked]
Subject: Re: server implementation question

"Kendrick M. Smith" wrote:
> Question: if a client uses a stateid, say in a READ request, and the
> credentials in the rpc request differ from the credentials which were
> used to open the file (and obtain the stateid), should the server
> return an error (even if the permission check for the file succeeds
> with the new credentials)?  I couldn't find anything in the spec which
> would answer this question...              - k

The RPC credentials and the stateid are not necessarily linked.  NFS
has always had a two part authentication, the first is the validation
of the RPC credential and accepting or rejecting the entire RPC
procedure
based on its validity.  The second is to make the principal of the
credential into a valid server identity which the NFS operation acts as.

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.  In the case of a Unix client
it is expected that a file may be opened using one identify and then
the process setuid (or setgid) itself to an different identity and
still access the same open file.  I can also think of other OSes
where the ability to access is intricately tied to the open where
other identify's attempts to access would be rejected.

But as John indirectly points out (even though he withdrew his comment)
the stateid is not cryptographically secure so using it as a permissions
check is ill advised.

	-David

---

From: Mike Eisler <[email-masked]>
Date: Mon, 04 Jun 2001 12:00:56 -0700

> 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