[tahoe-lafs-trac-stream] [tahoe-lafs] #308: add directory traversal / deep-verify capability?

[tahoe-lafs]

#308: add directory traversal / deep-verify capability?
-------------------------+-------------------------------------------------
     Reporter:  warner   |      Owner:
         Type:           |     Status:  new
  enhancement            |  Milestone:  2.0.0
     Priority:  major    |    Version:  0.7.0
    Component:  code-    |   Keywords:  vdrive newcaps verify repair
  dirnodes               |  privacy anonymity research
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------
Changes (by zooko):

 * keywords:  vdrive newcaps verify repair privacy anonymity => vdrive
     newcaps verify repair privacy anonymity research


Old description:

> We might split our current three-level directory capability structure
> (write,
> read, verify) into four levels: write, read, traverse, verify. The
> 'traverse
> cap' would be able to access the traverse cap of child directories, and
> the
> verify cap of child files. It would not be able to read child names.
>
> The issue is that, at present, the verifier manifest (a set of verifier
> caps
> for all files and directories reachable from some root) can only be
> generated
> by someone who holds a readcap for the root. This manifest generation
> cannot
> be safely delegated to some other party (such as a central allmydata
> server).
> So we're forced to decide between having customers expose their files to
> us
> (by giving us their root readcap) or being required to create their
> manifest
> (for file checking/repair) on their own.
>
> If we had traversal caps, then customers could give us the traversal cap
> instead of their read cap. We could still see the shape of their
> filesystem
> (and probably the length of their filenames, and the size of their
> files),
> but perhaps that would be little enough exposure that customers would be
> comfortable with revealing it. In exchange, we could provide the service
> of
> keeping all their files checked and repaired with less effort on their
> part,
> even when they leave their node offline for months at a time.
>
> The implementation would require a couple of pieces:
>
>  * dirnode capabilities would need to have a four-level structure.
> Writecaps
>    beget readcaps. Readcaps beget traversecaps. Traversecaps beget
>    verifycaps.
>  * I think this means that mutable file caps need an extra intermediate
> layer
>    as well: this is tricky, and will require some staring at the DSA
> mutable
>    file diagram to find a place that could accomodate it.
>  * Each edge entry contains five child items: (name, writecap, readcap,
>    traversecap, metadata)
>  * 'name', 'readcap', and 'metadata' are encrypted with a key derived
> from
>    the dirnode's readcap.
>  * 'writecap' is encrypted with the dirnode's writecap.
>  * 'traversecap' is encrypted with the dirnode's traversecap
>
> When we do DSA dirnodes, we should take advantage of the compatibility
> break
> to implement something like this. I suspect it will require changes to
> the
> DSA scheme as well.
>
> (there is probably a better name for this concept.. "walk cap"? "manifest
> cap"? "deep verify cap"?)

New description:

 We might split our current three-level directory capability structure
 (write,
 read, verify) into four levels: write, read, traverse, verify. The
 'traverse
 cap' would be able to access the traverse cap of child directories, and
 the
 verify cap of child files. It would not be able to read child names.

 The issue is that, at present, the verifier manifest (a set of verifier
 caps
 for all files and directories reachable from some root) can only be
 generated
 by someone who holds a readcap for the root. This manifest generation
 cannot
 be safely delegated to some other party (such as a central allmydata
 server).
 So we're forced to decide between having customers expose their files to
 us
 (by giving us their root readcap) or being required to create their
 manifest
 (for file checking/repair) on their own.

 If we had traversal caps, then customers could give us the traversal cap
 instead of their read cap. We could still see the shape of their
 filesystem
 (and probably the length of their filenames, and the size of their files),
 but perhaps that would be little enough exposure that customers would be
 comfortable with revealing it. In exchange, we could provide the service
 of
 keeping all their files checked and repaired with less effort on their
 part,
 even when they leave their node offline for months at a time.

 The implementation would require a couple of pieces:

  * dirnode capabilities would need to have a four-level structure.
 Writecaps
    beget readcaps. Readcaps beget traversecaps. Traversecaps beget
    verifycaps.
  * I think this means that mutable file caps need an extra intermediate
 layer
    as well: this is tricky, and will require some staring at the DSA
 mutable
    file diagram to find a place that could accomodate it.
  * Each edge entry contains five child items: (name, writecap, readcap,
    traversecap, metadata)
  * 'name', 'readcap', and 'metadata' are encrypted with a key derived from
    the dirnode's readcap.
  * 'writecap' is encrypted with the dirnode's writecap.
  * 'traversecap' is encrypted with the dirnode's traversecap

 When we do DSA dirnodes, we should take advantage of the compatibility
 break
 to implement something like this. I suspect it will require changes to the
 DSA scheme as well.

 (there is probably a better name for this concept.. "walk cap"? "manifest
 cap"? "deep verify cap"?)

--

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/308#comment:15>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage