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

[Zooko O'Whielacronx]

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