Subject: server implementation question

From: "Kendrick M. Smith" <[email-masked]>
Date: Sun, 3 Jun 2001 13:55:29 -0400 (EDT)

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

---

From: John Howard <[email-masked]>
Date: Sun, 03 Jun 2001 22:07:55 -0400

> would answer this question...              - k

Do we really need credentials in the READ request at all?  I was
thinking that the sessionID would be sufficient provided that
connections could not be hijacked.

John

---

From: John Howard <[email-masked]>
Date: Sun, 03 Jun 2001 22:08:59 -0400

Oops, wrong mailing list.  Please ignore my previous message.  --John
Howard

---

From: David Robinson <[email-masked]>
Date: Sun, 03 Jun 2001 20:15:53 -0700

> 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: RJ Atkinson <[email-masked]>
Date: Mon, 04 Jun 2001 08:32:41 -0400

>the stateid is not cryptographically secure so using it as a permissions

The above belongs in a "SECURITY CONSIDERATIONS" section 
someplace.  This sort of information needs to be clearly
documented as an aid to well-intentioned but naive implementers
and as an aid to users/system admins.

Ran
[email-masked]