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

Zooko O'Whielacronx zookog at gmail.com
Sat Jun 13 10:40:08 PDT 2009


On Fri, Jun 12, 2009 at 8:19 PM, Brian Warner<warner-tahoe at allmydata.com> wrote:
>
> Revocation is a complicated topic. As Kevin said, it basically requires an
> intermediary, which might either be a single proxy/gatekeeper or something
> distributed (like an intermediate tahoe directory that you can later empty).
> Any extra layer will hurt availability/reliability in hard-to-model ways
> (what if the proxy is down? what is the probability two directories are
> recoverable versus just a single directory?).

Revocation is complicated!  And we can't ignore it.  We probably need
to start using more precise terminology to discuss it.

I can think of three kinds of revocation that I might want.  One is
revocation of read authority to an immutable file.  I might want to
give someone the ability to read an immutable file and later revoke
that ability of theirs.  On the other hand, I don't want this very
much, because I know that they could have already downloaded it and
saved a copy and there's nothing I can do about it.  Ping Yee
suggested that the user interface should say "send the file" to
someone when you give them an immutable-read-cap (rather than "share
the file" or "sending a link").

The next is revocation of read authority a mutable file or directory.
This is more useful.  I may have given many people read-access to a
directory, and now I want to make it so that one of them won't be able
to see *new* updates that I make to that directory, but the others
will be able to.  This is a reasonable thing to want to do, and we
need to figure out how to offer this without losing too much
availability/reliability and without giving some central administrator
control over what everyone is allowed to read.

The next is revocation of write authority to a mutable file or
directory.  This is actually the most urgent!  Because if you need
this one, you can't just work-around it by some quick, safe (but
inconvenient) technique like you can with the previous one.  Here's an
example from real experience:  I had a blog on Tahoe at this address:
http://tahoebs1.allmydata.com:8123/uri/URI:DIR2-RO:hgvn7nhforxhfxbx3nbej53qoi:yhbnnuxl4o2hr4sxuocoi735t6lcosdin72axkrcboulfslwbfwq/wiki.html
.  Then one day I accidentally leaked the secrets which control write
access to the blog.  Now what I most need to do at that time is to
revoke those secrets.  (Note: all access control systems have the
problem that the authority used to allow access can leak and they need
to offer revocation of that authority -- this is not a problem unique
to capability access control.)

Fortunately this last one is also the easiest to implement in a robust
way -- we simply need to define a special "freeze" message that puts a
mutable file or directory into a state where it can't be changed again
(including that it can't be unfrozen).  If I had that, then after
updating my old blog to announce that it had moved to a new location,
I could freeze it and would then be safe from the danger that someone
else would take it over and make updates to it in my name.

Regards,

Zooko


More information about the tahoe-dev mailing list