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

From: Brent Welch <[email-masked]>
Date: Tue, 01 Nov 2005 13:21:05 -0800

>>>Garth Goodson said:

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

Sorry to chime in late on an old thread.  But, signature checking
is what the object protocol uses.  It assumes a key management
burden, which is why some won't like it.  But the model is pretty clean,
and I see this group struggling to solve the same problems.  There
are two basic ones

a) letting the data server enforce an access control decision made
by the metadata server
b) revoking access when an ACL changes

In the object storage protocol, the metadata manager returns a
signed capability that determines what the client can do with
the object named by the capability.  The 'cap' identifies the
object, the allowed operations, an expire time, and a cap version
number (also called a "policy tag").  The cap is signed so the
client cannot tamper with it.

Assume for the moment that the client sends the cap to the data
server who can verify it by checking the signature.  And, the
metadata server can revoke the cap by changing the cap version/
policy tag on the object.  Note, in particular, that an OPEN doesn't
require any communication with the data servers.  The metadata
manager can compute the capability because it shares a key
with the data server.  (Hence, key management.)

The client doesn't actually send the cap to the data server, but
instead uses the (signed) cap as a signing key to sign each
request.  This level of indirection can be verified by the
data server and it means the device working key isn't used as
often.

So, the challenge with the files protocol is to determine what you
need to do to achieve similar properties.  The simple approach has
the metadata server broadcast information to the data server at
OPEN time.  That will be expensive, especially when 1000s of clients
are simultaneously opening files spread across 10's of data servers.
The other approach suggested is that the metadata server returns
something to the client (akin to the signed cap) that can be
verified by the data server.  I'm not enough of an expert in GSS
and stateIDs and ACLs to suggest the best way to do this (my
head is still swimming a bit from this thread.)  But, I will
suggest that any scheme that parallels the object storage protocol
will have a scalability advantage.

I don't think I saw a resolution to this thread, did I miss it?

--
Brent Welch
Software Architect, Panasas Inc
Accelerating Time to Results(tm) with Clustered Storage

www.panasas.com
[email-masked]

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