[tahoe-dev] Authentication issues in Tahoe

Brian Warner warner at lothar.com
Mon Oct 18 20:53:19 UTC 2010

On 10/18/10 9:25 AM, Ravi Pinjala wrote:
> Yes, exactly. The possession of the file cap *is* the authorization.
> (As far as whether there are any plans to implement a more traditional
> authentication method, like username/password: I don't think so, but
> I'll defer to the much-more-experienced people on this list.)

Not really. In general, we prefer the approach of using capabilities as
the substrate and then layering other forms of access control on top of
that: we think it results in a system that is easier to understand, and
which avoids points of "baked-in" centralized control.

The only place where Tahoe has a concept of "username" is in the FTP and
SFTP frontends, where you must provide a file that maps
username+password to a rootcap. We had to do this because
username/password is the only authorization mechanism that those
protocols know about.

For sharing, it depends upon what's going to be shared. If Alice uploads
a file (or sees an existing file) and wants Bob to be able to see it,
she gives him the filecap. If she has a writecap to a directory, she can
either give Bob the full writecap (allowing them to collaboratively
modify the directory), or a reduced readcap (allowing Bob to see what
she uploads but not change anything), or a read-only immutable copy of
the directory (allowing Bob to see a snapshot of the directory but not
to see future changes). These can all be done with regular CLI tools and
sending caps around via email/IM/etc.

Traditional username-based authorization schemes frequently bring up a
notion of revocation: Alice wants Bob to read her foo.txt, but then
later she changes her mind and wants him to not be able to read foo.txt.
This is non-trivial, and we didn't want to build something for which
user's intuitions wouldn't match what they actually got (e.g. you hit
the "revoke access" button, but they'd already downloaded the file: can
you prevent that? detect that?). So we put off providing revocation
features until we could get a better feel for what people expect and
will accept.


More information about the tahoe-dev mailing list