[tahoe-dev] Access control and permissions on a tahoe grid

[Rufus Pollock]

2009/6/13 Brian Warner <warner-tahoe at allmydata.com>:
> On Fri, 12 Jun 2009 18:59:08 +0100
> Rufus Pollock <rufus.pollock at okfn.org> wrote:
[...]
>> 1. Can you have a "Grid Administrator" (with root-style permissions)?
>
> As Kevin pointed out, the answer is generally "no", but you'll want to
> distinguish "permission to read/write files" from "permission to consume
> storage space". Tahoe explicitly denies the first sort of permission: to see
> the contents of a file you must either create it or receive the filecap from
> someone who already knew it.

OK: so the only way to have a central entity with a full set of read +
writecaps is to have everyone upload through a central node.

[...]

> The reclaim-the-space part is trickier, and we implement it with
> garbage-collection. The storage servers don't know which directories hold a
> reference to any given file (because they aren't allowed to read the
> directories), so the rule is that clients are responsible for updating
> leases, and servers are supposed to keep a file's shares alive until all of
> the leases on that share have expired. This is less immediate than an
> explicit delete operation would be, but it avoids race conditions and removes
> the danger that the server might delete a file which is still being
> referenced by some other parent directory. (think reference-counting).
>
> So there isn't really an explicit "delete" permission, but write-permission
> on all of the directories that currently contain a reference to foo.jpg is
> pretty similar.

To clarify: this wouldn't actually delete foo.jpg -- it would just
unlink from all directories. To "delete" (as in reclaim the space)
you'd need for their to be no renewal of leases by all clients holding
a lease. (or have i misunderstood how leases relate to directories and
files).

[...]

>> To get (b)+(c) requires that when objects are created on the grid
>> (which may happen on a local node) that information is automatically
>> passed to the "Grid Administrator"? AFAICT the only way to achieve
>> this is to have all users only create objects on the grid via some
>> central node/api/upload point. Is this correct?
>
> Yes. Basically you're looking at hiding the Tahoe grid behind a proxy, and
> that proxy limits the operations allowed to users: they can't just upload an
> unlinked file (data->filecap), nor can they just create a new unlinked
> directory, but they can (upload+link) a file into an existing directory, and
> they can (mkdir+link) a new subdirectory of an existing directory.
>
> You could conceivably give out the readcap and let users download data on
> their own, without the proxy, but the Tahoe storage server protocol doesn't
> currently distinguish between read-authority and write-authority, so those
> users would also be able to upload unlinked files and create unlinked
> directories, which you want to be able to prevent.

So if I give someone a file readcap they can also write to the file?
That seems weird! I thought writecap and readcaps were different (or
do they only apply to people not on the grid -- i.e. those accessing
via the web interface ...)

[...]

>> 2. How do you control who can join a grid?
>>
>> Is there any way to configure my node only to talk to these other
>> nodes? Given that new nodes join a grid via an introducer I wondered
>> if there were some way to use the introducer for this function. (E.g.
>> I have to be a given a token which I pass to the introducer in order
>> to be "allowed in")
>
> The answer depends upon how you'd answer Kevin's question about "why do you
> want to do this". It's also strongly influenced by the current storage server
> protocol, which (as described above) doesn't split out upload-shares
> permission from download-shares permission.

This would matter if membership in the grid gives you ability to
upload whatever you want (and without any control from elsewhere).

It would also allow us to say: ok if you join the grid you agree to
register all your uploads with our distributed storage file system DB
over here.

> One reason to control who can join a grid is so that a storage-server
> operator can control who gets to consume their disk space. The Accounting
> project is our plan for this: it doesn't matter who can connect, as long as
> they can't consume space without some sort of authorization that you control.
> (our plan for Accounting involves authorized clients holding private DSA keys
> which correspond to a DSA public keys that's been added to the server's
> tahoe.cfg).

[...]

>> 3. Is it ever possible to revoke capabilities.
>>
>> For example, if I give you the writecap to directory X is there any
>> way to rescind that later on (i.e. can I change the writecap for that
>> directory without deleting it)?
>
> Nope, not yet. In the current release, sharing filecaps and dircaps is an
> irrevocable act. You'd need to introduce some out-of-band mechanism to
> control access carefully enough to provide strong revocation properties.

Thanks for the detailed explanation (which I've snipped)! I now
understand a lot better.

I should probably have emphasized that, from our point of view, we're
interested in revoking writecaps not readcaps -- after all the data we
store is going to be open and 100% world readable.

The issue here was that I might want to provide write access to a
directory to everyone but later on turn that off (to stop people
deleting stuff -- which seems to be a subtler issue than I thought
anyway).

Rufus