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

From: Nicolas Williams <[email-masked]>
Date: Wed, 21 Sep 2005 14:25:38 -0500

On Wed, Aug 31, 2005 at 04:13:03PM -0400, [email-masked] wrote:
> [I wrote]
> > > 	OR
> > > 	- using the ACL in the Open reply that issued the delegation
> > 
> [Dave wrote]
> > This seems dangerous. The client cannot reliably determine the
> > permissions of principalY by just examining the ACL returned. Even
> > without close or logout of prinicpalX a subsequent operation
> > by principalY on file foo may unexpectedly fail because the
> > client could not fully evaluate the permissions.
> 
> I suspect you are correct wr.t. current implementations.. I vaguely recall
> asking what the ACL in the
> write delegation should look like, back when I was first implementing
> delegations, and there didn't seem to be much consensus w.r.t. it.
> 
> Having said that, the RFC seems pretty clear [from Sec. 14.2.16]:
>            nfsace4         permissions;    /* Defines users who don't
>                                               need an ACCESS call as
>                                               part of a delegated
>                                               open. */

That's a *single* ACE in the delegation result.

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

---

From: [email-masked]
Date: Wed, 21 Sep 2005 16:21:43 -0400 (EDT)

>That's a *single* ACE in the delegation result.
Yep, I noticed that after I had sent the mail. However, I think the
statement is still correct, in that the above ACE allows certain users
(the one referred to by the "who" field of the ACE?) to avoid an ACCESS.
(I also recall an email thread I started back when I was implementing
 delegations, where there didn't seem to be concensus on what this ACE
 would look like and how clients should interpret it?)

My server currently returns it as:
type - allow
flags - none (0)
mask - any of Read, Write, Execute that permitted for the file's owner
who - OWNER@

but I have no idea if this is correct or not? rick

---

From: [email-masked]
Date: Thu, 22 Sep 2005 12:04:53 -0400 (EDT)

[Craig wrote]
> I'd aim for the nfsace4 to refer to the caller (as opposed to the
> owner), but it's not *wrong* to refer to some other user.

Hmm, not sure I see why. I could argue:
"The client will know the caller is allowed access because the Open
 succeeded. What it needs is an ACE that tells it other principals also
 have the appropriate access. As such, a who == caller doesn't seem
 useful."
What do you think?

At one time I had it coded so that it would use a "who" that
allowed as many users as possible to have access. For example, for
a Write Delegation (assuming no ACL on the file):
- if (mode & 0666) == 0666 --> EVERYONE@
  else if (mode & 060) == 060 --> GROUP@
  else --> OWNER@
For Read Delegations:
- if (mode & 0444) == 0444 --> EVERYONE@
  else if (mode & 040) --> GROUP@
  else --> OWNER@

However, after a mailing list discussion a long time ago, I changed it
to always use OWNER@. (I just can't remember why I changed it:-)

I've left the thread subject unchanged, because I think that the protocol
should allow other principals to do Opens locally on a client while the
client has a Delegation. I also believe the protocol should allow the
client to use a Delegation after the principal used to do the Open that
acquired the Delegation no longer exists (as an authenticated token
usable by RPCSEC_GSS) on the client.

A file server can choose to be more restrictive if it wishes to (and all
pNFS servers might choose to do that), but for the non-pNFS case I believe
the protocol should allow the above.

Why? Well I think it might affect performance over long delay network
paths, once clients figure out how to do large scale local caching.

Just MHO, rick

---

From: [email-masked]
Date: Thu, 22 Sep 2005 18:12:10 -0400 (EDT)

Oh, and I think my premise that "since a principal OPENed the file,
that principal can do more OPENs without checking the ACE or doing
an ACCESS is incorrect". For example:

Principal X OPENs foo for Reading
Server allows OPEN (which implies Principal X is allowed to Read the file)
	and issues a Write Delegation for foo to the client

Although it seems a little weird, I don't see anything in the RFC that
precludes a server from issuing a Write delegation to a client for an
Open for Reading. I'm not so sure it should do so unless the principal
(Principal X for the example) would have Write access for the file, but
I see nothing in the RFC that precludes that case. Sec. 9.4 states the
client must check permissions via the nfsace4 or an ACCESS Op. There
is no "implied permissions" that come with the Delegation.

rick

---

From: "Everhart, Craig" <[email-masked]>
Date: Wed, 21 Sep 2005 17:30:17 -0400

Craig 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Wednesday, September 21, 2005 4:22 PM
To: [email-masked]
Subject: Re: [nfsv4] pNFS, OPEN principals and ACLs

---

From: "Everhart, Craig" <[email-masked]>
Date: Fri, 23 Sep 2005 10:47:46 -0400

I agree with this.

I think it's important to distinguish the semantics of "stray entry from
the ACL" from "computed access permissions for a well-defined entity".
That is, given the cascaded ACL evaluation model, it wouldn't make sense
for the returned nfsace4 simply to return an entry from the ACL, which
the client wouldn't have the context to apply in any case.  Instead, the
returned nfsace4 would have to refer to the resulting permissions
(computed by the server) that apply to a given "who" entry.  So I'd
argue that the server shouldn't return a "who" of everyone unless the
given permissions were really applied to everyone--i.e. not "everyone
except these principals" or "everyone except these groups".

I actually like the model from, I think, Nicolas Williams: the nfsace4
specifies the "who" string for the caller's principal as well as the
computed permissions for that caller.  Of course the caller's
permissions will include the permissions necessary to do the open, but
they don't necessarily include permissions to do other operations in the
future, which is why it's useful to include them in the reply.  This is
basically a piggybacked ACCESS call result.

		Craig

-----Original Message-----
From: Noveck, Dave 
Sent: Thursday, September 22, 2005 8:15 PM
To: 'Nicolas Williams'; [email-masked]
Cc: [email-masked]; Everhart, Craig
Subject: RE: [nfsv4] pNFS, OPEN principals and ACLs

One case in which it can do this is when an ace specifying everyone is
provided.  For example, the server can tell the client that everyone can
read the file.

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]]
Sent: Thursday, September 22, 2005 6:29 PM
To: [email-masked]
Cc: [email-masked]; Everhart, Craig
Subject: Re: [nfsv4] pNFS, OPEN principals and ACLs

On Thu, Sep 22, 2005 at 05:58:29PM -0400, [email-masked]
wrote:
> [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?

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.

> 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.

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
--