Hi Greg, Thanks for the speedy response - sorry it took so long to get back to you. Comments inline:
On Wed, Jun 01, 2011 at 01:52:19PM -0400, Greg Troxel wrote: > toby cabot <[email protected]> writes: > > I have a question about sharing files with other people and I can't > > find the answer on the site but I hope this isn't a FAQ. If I run my > > own client with the web user interface, I imagine that I can share > > files by simply giving someone a directory URL. Could they then give > > You should be clear on the difference between a URL to the gateway, and > a URI which is a capability within tahoe. URIs get encoded in URLS, but > I'm getting fuzzy because I decided to stop using the Web User Interface > for other than checking server connectivity etc. (because putting > secrets in URLS in modern browsers seems like a bad idea). It sounds like an important concept is that the URI to a file/dir is a "secret". I'll try to explain it and please let me know where I stub my toe: "traditional" filesystem such as FAT/ext3/zfs/etc start at a well-known "root" and allow users to explore the contents of the filesystem from there. Because the root is well-known, each user would be able to do anything they wanted unless there were some sort of inline permission check, so these filesystems implement "ACL" permission checks to prevent users from doing things they can discover, but are not permitted to do. In other words, I can discover a directory's existence, but I might not be allowed to read from it. Tahoe-LAFS, on the other hand, has no well-known "root" - each directory tree is identified by a secret URI which would be very difficult to guess. Each directory URI acts like the traditional FS "root" in that users can browse down from it to see files in the tree below it, but they can't browse "up" to see other trees within the same FS. Because users cannot discover things that they're not permitted to, the traditional in-line permission checks implemented by traditional FS's aren't necessary. > > this URL to someone else, perhaps someone that I wouldn't want to see > > the directory? Is there an authentication component that I'm missing? > > Yes, they could. What you are missing is > > 1) that this is a capability system, not an ACL system. > > 2) if you handed them a decryption key for normal data, they could grab > and download the data. They could then hand it out. > > Basically, if you don't trust people to keep things secret, you can't > share with them. This isn't about tahoe, or rather tahoe has no magic > bullet for this. IOW, When I share a URI with someone, I place the same trust in them that I would if I were to grant them traditional FS permissions on a directory, and the ways in which they can honor or betray that trust are similar. > > If I give someone a URL to a directory can I later revoke that URL > > somehow but still be able to access the directory myself? > > No. But you can move the files in it to a new directory and hope the > original directory gets garbage collected. I understand that a trust in in a traditional FS can be actively subverted in the same way that it could in Tahoe-LAFS, but what about mistakes? Let's say, for example, that I want to respond to an email and my reply has a capability URI in it, but I hit "reply all" by mistake, or my crappy email client auto-fills "Jones, Fred" instead of "Jones, Frank" and I don't realize before I send it. If I realize I've made a mistake like this I'd like to be able to correct it and know that it was corrected rather than hope for it to be corrected at some unknown time in the future. > But again, if they copied the data, you can't revoke that. Sure, but let's say I realize what I've done before they've copied it. >From what I've heard, with the traditional FS I can close the barn door and know that it's closed. With Tahoe-LAFS I can only ask for the barn door to be closed at some point in the future. > It's interesting that this comes up in tahoe much more so than in otheer > filesystems. People don't seem to ask: > > if I have a filesystem, and I let someone read a file, and then I > "chmod 700" it, how can I be sure they didn't keep a copy? Isn't it a > bug that the filesystem doesn't enforce removing all their copies? > > about other filesystems. I don't ask that question because I believe that I know how traditional filesystems work (but I might be wrong) since I've been using them for a while and they've been around a lot longer than that. Tahoe-LAFS, on the other hand, is new and interesting so I'm trying to figure out how it works. I tend to do that by comparison to things I'm familiar with, so I start out with "oh, it says it's a file system and I know about some other file systems so it probably works like them." It turns out that Tahoe-LAFS is pretty radically diffent than Windows or Unix file systems in some really interesting ways. Thanks again for helping me! _______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
