Subject: Re: [nfsv4] pNFS, OPEN principals and ACLs

From: [email-masked]
Date: Thu, 22 Sep 2005 17:58:29 -0400 (EDT)

[Nico wrote]
> I think it's simpler.  The client does an OPEN as a given principal, the
> server then tells it what access that principal has to that file and
> what the principal's "who" name is as far as the server is concerned.
> 
> I think the plural "users" that rick quoted from RFC3530 is misleading
> -- that ACE is not supposed to represent more than one user, the one
> that opened the file.

Well, here's the first sentence of the last para in Sec. 9.4:
   The use of delegation together with various other forms of caching
   creates the possibility that no server authentication will ever be
   performed for a given user since all of the user's requests might be
   satisfied locally.

To me, that says that the ACE can apply to other "users" than the one
that did the OPEN, otherwise how could it never authenticate to the
server, since it was the one that did the OPEN?

Higher up on pg 104:
   The nfsace4 passed with delegation can be used to avoid frequent
   ACCESS calls.  The permission check should be as follows:

   o  If the nfsace4 indicates that the open may be done, then it should
      be granted without reference to the server.

   o  If the nfsace4 indicates that the open may not be done, then an
      ACCESS request must be sent to the server to obtain the definitive
      answer.

It seems "if the nfsace4 says the OPEN can be done, that's all that
needs to occur". No suggestion that it only applies to the principal
that did the OPEN, from what I read.

Then the next para:
   The server may return an nfsace4 that is more restrictive than the
   actual ACL of the file.  This includes an nfsace4 that specifies
   denial of all access.  Note that some common practices such as
   mapping the traditional user "root" to the user "nobody" may make it
   incorrect to return the actual ACL of the file in the delegation
   response.

This seems to say that the server can use a more restrictive nfsace4
if it wishes to, and recommends that for cases where "user mapping" isn't
straightforward. (The last sentence above seems to suggest that
the actual ACL could be returned. But, a single ACE can't represent an
"actual ACL", so what does this mean?)

Since Sec. 9.4 doesn't explain how the nfsace4 is used to check
permissions, I have always been concerned about differing interpretations
of it. Yours, as stated above, could be one of many.

rick

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

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 22 Sep 2005 17:29:10 -0500

> server, since it was the one that did the OPEN?

How can it?  An ACE can only have one subject.  Even assuming a group as
a subject the client may not be able to resolve the group to the same
set of users as the server.  Any implication that the client can
determine, given just one ACE what the rest of the ACL on that file
looks like and how to interpret that is clearly, clearly incorrect.

> that did the OPEN, from what I read.

The client can ultimately do whatever it well pleases.  It can open a
file as one principal that has access to it and then turn around and
give access to that file away to any and all who ask the client.

So what?  That doesn't mean that the client can do what the server would
have done had the client done an ACCESS for any other users on it asking
to access that same file.

Nico
--