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

From: "Everhart, Craig" <[email-masked]>
Date: Thu, 22 Sep 2005 14:28:36 -0400

Well, the complication seems to be whether the client's interpretation
of the "who" string in the nfsace4 is the same as that of the server.
So, for instance, a server might supply an ACE for user "[email-masked]",
presumably to help the client just in case "[email-masked]" logs in or
refers to this file, but in so doing is the server trusting the client
to recognize "[email-masked]" as a user?  It's clear that the client and
server agree on who the caller is (even if they might not agree on the
print-name for that caller's principal or the groups that the caller is
in), but it's not clear that they can agree on much else.  (How would
the client know who the server thinks is in group BAR?)  Your EVERYONE@,
GROUP@, and OWNER@ model below seems to seek some refuge in their
"common" interpretation of the file attributes, but I'm not sure I know
how to go past "EVERYONE@" and "the caller".

To your point, the client knows that a given OPEN succeeded, but it
might well be useful to have cached information governing other accesses
that might be made in the future.

		Craig

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

[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

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

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 23 Sep 2005 12:03:21 -0500

> how to go past "EVERYONE@" and "the caller".

I agree.  I think the subject of the ACE is not something that the
client can use to do much other than tell whether: a) the principal was
the owner of the file (who == OWNER@), b) all other cases.

For example, who == EVERYONE@ could mean that the server couldn't figure
out what the client principals _username_ is, or that the client matched
an ACE on the file's ACL whose subject was EVERYONE@.  And GROUP@ might
mean that an ACE with a group subject was matched, or whatever.  Any
non-magic who value might well be a hint from the server to the client
as to what the client principal's username as far as the server is
concerned (this could be helpful later when the client wants to set ACLs
on other files on the same server; but the client can't rely on getting
this info in OPEN).  And the server's ACL semantics seem likely to
impact this.

So the client really can't reliably tell much from the subject of the
ACE in the OPEN reply besides what access that client principal, and
only that one, has to that file.

> that might be made in the future.

Right.  And as to Rick's point re: being able to get write delegations
while opening only for read, that could indicate the intention to write
eventually, or simply to get a notification when the file gets written
to.

Nico
--

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 23 Sep 2005 13:17:25 -0400

On Fri, Sep 23, 2005 at 12:03:21PM -0500, Nicolas Williams wrote:
> eventually,

The delegation grant is made by the server, not the client, so it
doesn't communicate anything about client intentions.

There's any number of reasons why the server might consider it
reasonable to give the client exclusive access even though the client's
only doing a read open for now.

> or simply to get a notification when the file gets written to.

I'm not sure what you meant there.--b.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 23 Sep 2005 12:22:44 -0500

> doesn't communicate anything about client intentions.

Doesn't the client have to ask though?

> I'm not sure what you meant there.--b.

If another client opens the same file for writing I'd expect the first
client to get a callback request to return the delegation.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 23 Sep 2005 13:31:51 -0400

> Doesn't the client have to ask though?

No.  It asks for a certain kind of open, but it has no way to tell the
server what (if any) kind of delegation it would like returned.

> client to get a callback request to return the delegation.

Right, but this isn't a reason to prefer a write delegation over a read
delegation--both have the property that they guarantee callbacks on
other clients' opens for write.

--b.