[tahoe-dev] Tahoe Access Control

[Brian Warner]

On 6/3/11 3:28 AM, Greg Troxel wrote:

> So, it seems that a directory writecap enables one to:
> 
>   change the directory (as expected)
> 
>   read the write part of writecaps stored in the directory
> 
> while a directory readcap enables one only to
> 
>   read the read part of writecaps stored in the directory, or the
>   matching readcap that must always be present next to a readcap

Yup!

> .. or whether a dir looks like:
> 
>   name readcap [writecap]
> 
> and the whole writecap is encrypted in a key that is only in the parent
> writecap.

Yes, just like that. There's a table with three columns: name, readcap,
encrypted-writecap. The whole table is serialized and stored in a
regular mutable file (meaning the table is encrypted by the directory's
encryption key, contained in the directory's writecap).

In addition, the contents of each cell in the third column
("encrypted-writecap") is encrypted by separate key that is derived from
the directory's encryption key. It uses src/allmydata/util/hashutil.py's
mutable_rwcap_key_hash() function (which also involves a salt, since
we're never allowed to use the same key twice). As a result, the child
writecap is "superencrypted": encrypted twice.

The actual code is here, in _encrypt_rw_uri():

 https://github.com/warner/tahoe-lafs/blob/master/src/allmydata/dirnode.py#L173

This gives us tahoe's "transitive-readonlyness" property: dir-write-cap
holders can see all three columns (including the writecaps, if any),
whereas dir-read-cap holders can only see the first two. Some of the new
mutable-file formats that David-Sarah has been working on extend this to
four or five columns (adding a deep-verify / traversal cap, and maybe a
shallow-verify cap).

> Is the URI: format (textually) in the directory?  Or some binary format?

It's a verbatim copy of the full human-readable cap string, starting
with "URI:". We've thought about packing it in some binary format (to
make the directories smaller), but we figured that format shouldn't be
specific to dirnodes, so the job is really to define a
"non-human-readable minimally-redundant binary cap format", with a
prefix that can be distinguished from the existing "URI:TYPE:.." format,
and we haven't gotten around to doing that yet.

> I also don't see a CLI command to take a writecap and return a readcap.

Nope. In the WUI, if you use the "More Info" link, you'll see the
corresponding readcap (and verifycap) for any writecap. I wasn't sure
that this operation was common enough to warrant a CLI command, although
I think it'd at least warrant inclusion in the output of "tahoe debug
dump-cap". If there were a dedicated CLI command, maybe "tahoe
attenuate-cap"?

> "tahoe get" on a directory didn't work:
>   Error during GET: 302 Found
> 
> but I expected to get the directory contents.

The dircap indicates both a filecap (for the backing store) and a
certain interpretation of its contents. To see the backing store, you
need to convert the dircap to a filecap. The "More Info" WUI page
includes this too, but you'll have to cut-and-paste the filecap out of
that page and into your "tahoe get" command.

(one goal I have for new cap formats is to compose this better: if caps
were S-expressions, they could be like (interpret-as-directory
(mutable-file-cap)) )

(huh, "302" is an odd error message, though, we could probably do better
than that)

cheers,
 -Brian