[tahoe-dev] Tahoe Access Control

[Greg Troxel]

Brian Warner <warner at lothar.com> writes:

> 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).

Thanks.  This was much clearer after I looked at the contents via
s/URI2/SSK/.

>> 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.

If 'tahoe get' unpacks it all, that seems fine.  Otherwise it seems like
an optimization that doesn't help and just makes things harder.

>> 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"?

I think it's a bug if anyone is every encourage to use the WUI:

http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1415

> 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.

For which I'd have to use the WUI which seems unsafe.

> (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)) )

perhasp we can rewrite all of tahoe in scheme, too :-)

> (huh, "302" is an odd error message, though, we could probably do better
> than that)
-------------- 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/b5374640/attachment.pgp>