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

From: Mike Eisler <[email-masked]>
Date: Thu, 8 Sep 2005 19:45:34 -0700 (PDT)

--- Nicolas Williams <[email-masked]> wrote:

> On Wed, Aug 31, 2005 at 12:08:45PM -0700, Mike Eisler wrote:
> > 
> > 
> > --- Nicolas Williams <[email-masked]> wrote:
> > 
> > > On Tue, Aug 30, 2005 at 08:22:39PM -0700, Mike Eisler wrote:
> > > > What of the issue Garth raised? I propose that we introduce
> > > > two new operations, GETFD and PUTFD. Like GETFH, GETFD is invoked in the
> > > > same COMPOUND as OPEN, after OPEN. GETFD returns a file descriptor.
> > > > PUTFD injects a file descriptor. Unlike file handles, file descriptors
> > > > do not persist. One a file is CLOSEd, the file descriptor used
> > > > in the CLOSE is disposed of. PUTFD is used for any operation on
> > > > a regular file that takes a stateid. PUTFD is used instead of PUTFH.
> > > ...
> > > 
> > > Sounds close to an access token; why not deal with NFS as the backend
> > 
> > It is solving the same problem as the access token, but it isn't an access token.
> 
> But without a metadata server<->data server protocol the FD is not
> enough.

Any pNFS implementation likely has a data server to metadata server protocol
already. An easy template for a protocol that lets the data server verify access
via the metadata server already exists: NFSv4's ACCESS operation. And that is sufficient
for producing the FD. It's functionally equivalent to what Garth proposed
when he kicked off this thread, but without overloading stateids.

Access tokens/capabilities are not easy, and they are easier to get wrong.

> > > protocol as with an OSD...  The client could get the FD from the
> > > metadata server and then PUTFD the same thing on the data servers.  To
> > > build a token out of this is easy, just structure it something like,
> > > roughly:
> > > 
> > > { FD-data = {issuer, fd-index-local-to-issuer, expiration, FH, princ name,
> > > 	     access-type},
> > >   key-id, HMAC(K, <FD-data>) }
> > > 
> > > (public key crypto would be better, but slower)
> > 
> > Where does key K from from? A private protocol between the metadata and
> > date servers? I prefer securing this via the open protocol rather than trusting
> > the implementation to secure the private protocol.
> 
> It could be a long-term key shared between each metadata and data server
> pair, say.  That'd take no more configuration than it would take to
> establish trust between them for direct communications between them.

Long term keys have this problem: when compromised, it is painful to re-key.
Thgis is why symmetric key Kerberos authentication and ticket granting
services are well secured. Whereas, metadata and data servers have to be
opened up to be useful. The less compromisable crypto material on each,
the better.

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

---

From: Marc Eshel <[email-masked]>
Date: Fri, 9 Sep 2005 10:20:53 -0700

If we are going to require NFSv4 for the data server we might as well 
require pNFS for the data server and do it right. Having the metadata 
server communicate with each data server at least twice for each 
open,read/write,close sequence is to much. I think we should consider this 
proposal or have an alternative that we minimize the metadata server and 
data server communication.
Marc.

---

From: Mike Eisler <[email-masked]>
Date: Wed, 21 Sep 2005 13:28:44 -0700 (PDT)

> require pNFS for the data server and do it right. Having the metadata 

I agree. Hence my proposal for GETFD and PUTFD.