[tahoe-dev] question about sharing...

[Greg Troxel]

toby cabot <toby at caboteria.org> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20110604/d8cb96d4/attachment.asc>