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

From: [email-masked]
Date: Thu, 22 Sep 2005 15:26:52 -0400 (EDT)

[Craig wrote]
> 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?

I'd say that's up to the client (or client implementor, if you prefer).
If the client is confident it "knows" who "[email-masked]" is, then fine,
otherwise it can do an ACCESS Op using a credential for whoever it "thinks"
might be "[email-masked]".

However, I think you do make a good point w.r.t. the difficulties relating a
"who" in an ACE with a RPCSEC_GSS principal that has appropriate access.
I understand current clients are choosing to do ACCESS Ops, and I suspect
that this is part of the reason why?

[Craig's good stuff snipped]
> 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.

And I would say that a client can cache the fact that "principal X" OPENed
the file when the delegation was issued and, as such, "principal X" shouldn't
need to check the ACE nor do an ACCESS Op for further OPENs, while it holds
the delegation. Sound ok?

rick

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

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 22 Sep 2005 15:54:28 -0500

> might be "[email-masked]".

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.

Nico
--

---

From: Marc Eshel <[email-masked]>
Date: Thu, 22 Sep 2005 15:15:02 -0700

> -- that ACE is not supposed to represent more than one user, the one

So from reading this thread and the thread Bruce started on "Eliminating 
stateid's from pnfs IO" it sound like everyone agrees that there is a need 
for some new call from the client to the data server. It was suggested to 
use GETFD/PUTFD but there are some objections since it requires some key 
management. Some people just prefer the using the stateid. Others are in 
between. What if we add a new call, I will call it pOPEN for now, that 
will propagate all the information from the metadata server to the data 
server through the client. This call will include the principal that did 
the open of the MDS, real stateid, FH, open mode, and lock state that the 
MDS provided on open. 
Now some implementations can use the a backend protocol to provide all 
this information from the MDS to the DS tagged with the stateid and when 
the clients calls the DS with that stateid the DS will already have the 
capabilities for this user.
Other implementation might use the information provided by pOPEN to verify 
that the user has or can get the capabilities that the MDS promised. This 
can be done by the DS checking with the MDS, or the MDS just making sure 
not to give those capabilities to another user so when the DS tries to get 
a lock for example it will get for sure.
Maybe I am assuming to much about people opinions but if I am completely 
wrong maybe someone else can try to summarize what we do agree on and what 
we don't so we can make some progress to consensus.
Marc.

---

From: Mike Eisler <[email-masked]>
Date: Fri, 23 Sep 2005 11:04:45 -0700 (PDT)

> > -- that ACE is not supposed to represent more than one user, the one

No that's not correct. I think though, that given that
people want the delegation ACE to be different than it is, it
would be best if those folks ignored the delegation ACE and just
sent ACCESS or OPEN requests to the NFS server each time a process
wants to open the file.  
 
> management. Some people just prefer the using the stateid. Others are in 

That's also not correct. GETFD/PUTFD doesn't require key management.
All it requires is that the data server be able to determine the
access rights of the calling principal to use the file. I later
augment the GETFD proposal to include the stateid the metadata server
returned from OPEN, so the requirement is that data server know from:
  fh
  stateid
  principal
  requested access
whether the principal is allowed to access the filer. One possible method for
determination can be the call from the data server to the metadata server
to ask.

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 23 Sep 2005 13:33:57 -0500

> sent ACCESS or OPEN requests to the NFS server each time a process

What's not correct?  Just what exactly is that ACE supposed to mean?

> That's also not correct. GETFD/PUTFD doesn't require key management.

Right.  Something else I proposed did -- never mind that.

> determination can be the call from the data server to the metadata server

And that makes plenty of sense to me, particularly if this call is part
of NFSv4 too.

---

From: Marc Eshel <[email-masked]>
Date: Fri, 23 Sep 2005 11:39:55 -0700

> determination can be the call from the data server to the metadata 
server
Sorry I misseing it. So you just transfer the information trough the 
client without encryption and the data server will just have to verify 
that the principal is permitted to do the read or write operation and that 
all the right locks are held. The data server doesn't have to check with 
the metadata that the principal really opened the file in the right mode. 
Although we do require that the client do so.
Marc.

---

From: Mike Eisler <[email-masked]>
Date: Fri, 23 Sep 2005 11:51:10 -0700 (PDT)

> the metadata that the principal really opened the file in the right mode.

Actually it does check that because the stateid that the client got back from
the metadata server is sent to the data server who then sends it do the
metadata server. This way the share reservation the metadata server
granted to the client is enforceable by the data server on each I/O.

---

From: Garth Goodson <[email-masked]>
Date: Fri, 23 Sep 2005 12:02:57 -0700

Mike Eisler wrote:
>>>whether the principal is allowed to access the filer. One possible 
>>
>>method for
>>
>>>determination can be the call from the data server to the metadata 
>>
>>server
>>
>>>to ask.
>>>
>>
Alternatively the stateid, principal, access, etc. would have to be 
signed by the metadata server so that the data server could validate it 
without checking with the metadata server.  Not sure if we want to go 
there though...  It may be possible for implementations to do this if we 
have some type of opaque data that is part of the FD.

-Garth

---

From: Marc Eshel <[email-masked]>
Date: Fri, 23 Sep 2005 12:57:02 -0700

> granted to the client is enforceable by the data server on each I/O.
I thought that the PUTFD/GETFD proposal would reduce the need for a 
message from the metadata server to the data server on every open/close 
request. This proposal does not reduce the number of messages in the 
backend. Can you remind me what are the benefits of this proposal, which 
problem are you solving, since it changed from the initial GETFD/PUTFD 
proposal.
Marc.