[okfn-help] Fwd: Access control and permissions on a tahoe grid

Fri Jun 12 19:02:27 BST 2009

I've just sent this enquiry through to tahoe-dev mailing list. These
access control issues seem the most important things to resolve re.
progress with our open data grid.

Rufus

PS: news of our work on the open data grid has travelled fast: they
list it as the latest news item on their front page!

---------- Forwarded message ----------
From: Rufus Pollock <rufus.pollock at okfn.org>
Date: 2009/6/12
Subject: Access control and permissions on a tahoe grid
To: tahoe-dev at allmydata.org

Hi,

First off, I wanted do say a big thank-you for developing Tahoe --
it's a great piece software serving a really important function.

We've just started an "Open Data Grid" for storing "open data"
(<http://grid.okfn.org/>) using Tahoe, and we're going to be doing a
lot more work with it over the coming months.

In using Tahoe some questions have come up which we haven't been able
to resolve on our own by trawling the the archives! The most important
for us at the moment are about access control and permissions and I've
set them out below. Hope this isn't too much in one go and any info
you can give would be much appreciated.

Regards,

Rufus Pollock
Open Knowledge Foundation

1. Can you have a "Grid Administrator" (with root-style permissions)?

As I understand it from the documentation the ability to do stuff with
objects is controlled by the capability URI you have. If you have a
readcap you can read, if you have the writecap you can write etc.
Furthermore, these capability URIs are created when the object is
created and made available /to the creator/.

In our setup we want people to be able to "donate" nodes to the grid.
At the same time there needs to be some way to monitor/control what
people upload (the aim is to store open data of general interest not
someone's personal backups or their CD collection) and we also want to
ensure not just anyone can come and delete objects.

What this suggests to us is we want a "Grid Administrator" role with
root style permissions:

a) A "Grid Administrator" can see all objects (files/directories)
created on the grid.

b) "Grid Administrator" has full access to all objects (in particular,
can delete them if necessary)

c) We don't (always) make the writecap world-available.

As I understand it, to ensure a) we need every node owner to create
objects within a designated root directory (otherwise their
directories and files will be hidden from everyone else on the system
-- as one would want for privacy ...).

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?

If so, while not that big a problem ATM -- we can just write our
mini-webapp to handle uploading centrally -- it isn't perfect in the
long run. It would be nice if there were a way for nodes to share
permission info (perhaps via the introducer) just as they share info
about what other nodes exist.

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")

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)?