[tahoe-dev] Tahoe Access Control

[Greg Troxel]

Brian Warner <warner at lothar.com> writes:

> On 6/3/11 11:45 AM, Zooko O'Whielacronx wrote:
>> On Fri, Jun 3, 2011 at 4:28 AM, Greg Troxel <gdt at ir.bbn.com> wrote:
>>>
>>> But, in wiki:Capabilities, it says that a directory is just a mutable
>>> file with special interpretation.
>> 
>> This is perhaps a misleading statement. The "special interpretation"
>> includes an added layer of decryption. Probably that statement should
>> just be struck from wiki:Capabilities.
>
> Hm, I kinda disagree. The "special interpretation" means parsing the
> file's contents to build a mapping from child names to child caps, then
> providing a different set of methods (dirnodes have
> list/get/add/replace/remove, files have read/write). (ok, plus the extra
> decryption, but that's less significant than the table-parsing).
>
> Maybe we should clarify it to explain that directories are *backed* by
> files. I remember using that "just a mutable file" phrase to teach the
> reader that they didn't need to be afraid of dirnodes; that they were
> re-using existing technology (which the reader would already understand,
> having read about mutable files in the previous chapters), and only
> emphasizing the new parts (the layer of interpretation that makes
> dirnodes special).

As someone trying to understand, without reading the code, something
like:

  A directory is stored as a mutable file.  It contains a mapping from
  names to three items: a read-only capability to the item, a read-write
  capability to the item (optional), and attributes such as modification
  times.  The read-write version of the capability is further encrypted
  in a key that is contained in directory writecaps but missing from the
  corresponding readcap.

would be sufficient (from using SSK instead of DIR2 and reading the
output with emacs).

I see your point about making a directory an abstract object that is
implemented by mutable file storage, but I think that deviates from unix
filesystem nomenclature enough not to be helpful.  The above sort of
says "instead of an inode, we use caps, and we add metadata about the
time the object was added to the directory".

>>> but I expected to get the directory contents.
>> 
>> Change the URI from URI:DIR2etc. to URI:SSKetc.
>
> Oh, I just thought of a precedent for this *not* working as you
> expected. Once upon a time in the UNIX world, when directories were
> fairly new, you could 'cat' or 'vi' a directory, and you'd get a
> weird-looking file with some filenames and some other binary gunk. In
> theory you could probably edit that "file" to modify the directory, but
> nobody sane would do that directly. Only tools like "mv" did stuff like
> that, and eventually that functionality was moved down into the kernel
> and the filesystem code.
>
> Later, when the authors wised up and realized that allowing this sort of
> pseudo-casting wasn't helping anyone but filesystem hackers, they made
> it an error to use open() on a directory. Tahoe's webapi behaves like
> the latter/wiser UNIX interface.

I can do "cat ." on NetBSD 5.1 and pipe it to od and get inode numbers
out (with effort, and header files).  As far as I know that's always
worked, but I haven't tried on Linux.  (Amusingly ls calls getdents()
which returns things that look like UFS inodes for any filesystem.)

(I of course agree that writing to directories is banned, for good
reason.)

It also seems like when I use a writecap to fetch a directory that the
contents should have the embedded writecaps decrypted for me.


So I think the write bug is not that 302 is a wierd error message, but
that the contents aren't a) returned and b) have writecaps decrypted
with writecaps.

-------------- 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/9d09f405/attachment-0001.pgp>