On Sat, 22 Nov 2008 17:16:33 -0800 Nathan <[EMAIL PROTECTED]> wrote: > The idea is to represent the ability to create a new file or directory > as a capability.
Yeah, our basic plan is to express this "allocate storage" capability as a private key (or a certificate chain that references some private key). > The alteration would only change the mkdir and new_file operations to: > mkdir(creationcap) -> writecap > new_file(creationcap) -> writecap Yeah, but my current thinking is to require the creationcap for update_file() and update_directory() too. I'm intrigued by the properties we get if that's not required, though. OTOH, if you can't upload a new file, that reduces the number of ways you might usefully update_directory() (you could only delete a child or add some pre-existing child that you already knew about). > A minimal implementation might configure the creationcap by requiring > the user to place a public key representing the grid-wide creation > capability prover into their tahoe config. The grid owner would > carefully hand out the private key. I think that matches what our plans are, except that I'd express it as: The storage server operator places a public key in their tahoe config. The storage server operator is thus saying "I am willing to provide storage space to anyone who holds the corresponding private key, or has been authorized by someone who holds that key". A lot of the Accounting work is tied into how the authorization/delegation process is tracked. For allmydata, we'd have a single master private key, and the storage servers would be configured with the matching public key. Each account-holder has their own personal private key, and when you sign up for an account, we sign your personal key with the master one. The account-holder then presents a chain of (signature, personal key) to the storage server, which validates the chain and accepts the write request. In practice, there are a lot of details involved: getting from posession of an authorized private key to a server accepting your request takes several steps, and there are replay attacks and server-1-spoofs-user-to-server-2 attacks to be dealt with. We're using the term "furlification" for this process: getting from public/private keys to a secure reference to some empowered object facet. > Is implementing this simple? Does it represent a meaningful axis for > representing capabilities? Not simple, but yes, I think it's basically the direction we're heading. We need the delegation / certificate-chain bit, so we can keep track of who created each share, for accounting. It seems natural to combine this with storage authority: the key represents the right to create shares that are labeled "Bob" (you can't create shares labeled Alice, you can't create unlabeled shares). cheers, -Brian _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
