toby cabot <[email protected]> writes: > 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
Yes, that's very true. > my toe: "traditional" filesystem such as FAT/ext3/zfs/etc start at a Let's not forget FFS :-) But yes. > 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. That's true, but the point is that the file's contents are stored on a disk under the control of an operatig system kernel, and the access control model is that the keeper of the bits makes access control decisions based on identities (uid and gid). > 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. It's more subtle than that. Each file (and hence directory, which is a special kind of file) is stored encrypted so that the servers cannot read it. So a tahoe URI is a combination of several things, including for this dicussion most importantly: storage index - how to get the ciphertext. This is very much like an inode number encryption key - how to decrypt the ciphertext. This has no analog in traditional filesystems. > 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. True, but when you start reasoning about revocation, you have to think about the underlying mechansisms and the analogy is no longer useful. Also, trust is a word that crypto people are nervous about. I use it to refer to judgements that humans make about other humans, and try to use it only for that. For protocol analysis, we are concerned about "if someone has bits X, can they do Y". The trust bit is about if you are comfortable with person Z having bits X, but to make that decision you need to understand what Y is. > 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. That's a hugely important point. It has parallels in traditional filesystems - what if someone types their password or other access control information in the wrong window? Or if you put something sensitive in a reply and it doesn't get encrypted because you forgot to check encrypt. But URI sharing is a bit scary - I haven't really done that since I'm looking at tahoe as a backup mechanism more than a sharing mechanism. A related point is what happens if you use the WUI and it leaks URIs somehow (stored in recently visited, synchornized to some bookmark server, sent to anti-phishing filters, etc.). Because of that, I've decided not to use the WUI, which is leading to me complaining that the CLI can't do some things that the WUI can. It's my way of being helpful to the community :-) >> 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. That's true for immutable files. For a directory, you can unlink the contents and push out a new version. But I don't think there's been any analysis of how effective this is. >> 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. Fair enough - I just found in interesting to see that people (not you specifically) seem to expect security properties from tahoe that they don't get in other filesystems.
pgpbFwOhzqeTx.pgp
Description: PGP signature
_______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
