Re: Redirects and Revocation in a Capability Filesystem

On Mon, Nov 10, 2014 at 2:27 AM, Rob Meijer <rmeijer-qWit8jRvyhVmR6Xm/[email protected]> wrote:

> Is there any need for these capabilities to be persistently stored
> in the file-system


The capabilities are just byte strings. They can be stored anywhere.


>
> I have some trouble picturing an index on a file-system without a single
> root node.


An index is just a list of names and some attributes (in this case,
attached names) stored in a format for cheap lookup. Root nodes aren't
essential for indexing. I'm sure you know what an adjacency list [1] is. In
this case, the index is effectively just an adjacency list, albeit with
better sorting properties, plus a little extra for redirects.

[1] http://en.wikipedia.org/wiki/Adjacency_list



Even more picturing it in a file-system where the file-system
> itself is subject to the same POLA discipline as its clients


An index itself needn't possess any authority over the file system. In
terms of Rumpelstiltskin tree hashes, an index would only contain locator
capabilities, in addition to the destination for each redirect.



any advantage from 'half the objects' and 'tiny membrane'
>

The membrane approach has a cost proportional to the average coverage of
each membrane, times the number of membranes. The index approach has a size
fixed based only on the primary file system.

I plan to use a great many redirects, both as revocation points and as a
convenient means of 'mounting' shared resources into a user's or
application's space.


>
> Interestingly, my design had a similar name-stability properties that I
> consider to be a potential security vulnerability.
>

I consider stability very desirable for reasons unrelated to security.

I agree the sort of situation you describe, where two different 'bob'
objects for Bob Bobson vs. Bob Carols might be confused, is a concern for
direct human manipulations.

OTOH, I think this idea of forgetting what has been granted to whom might
be a bigger deal than just accidental reuse of names. It applies to all
sorts of scenarios.

I think that I would encourage best user practices such as creating and
redistributing a new 'team' directory each year, to get a fresh start. So
you'd have `myteam2013` and `myteam2014` and `myteam2015` and so on.


>
> I understand. Just be careful knowing that ACID doesn't come free. Using
> database technology will help avoid TOCTOU issues like the one I
> mentioned, it might however do so by implementing rather broad locks
> during some operations


Yes, BerkeleyDB holds page-level locks for the duration of a transaction.
It will also detect deadlocks and abort transactions to resolve them.



Do you rely on the ACID as supplied by this database technology

to make revocation within a cyclic-graph concurrency safe?


Revocation within a cyclic graph is still just deleting a single redirect
object.

I rely on ACID to support useful invariants my programming model, and to
improve data model consistency. I suspect it is possible to 'freeze it up'
for a couple seconds if developers aren't careful to ensure operations have
predictable timing behaviors.

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk