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. cheers, -Brian _______________________________________________ tahoe-dev mailing list tahoe-dev@tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev