Re: Redirects and Revocation in a Capability Filesystem

On Thu, November 6, 2014 20:12, David Barbour wrote:
> On Thu, Nov 6, 2014 at 11:59 AM, Rob Meijer <rmeijer-qWit8jRvyhVmR6Xm/[email protected]> wrote:
>
>>
>> Do these choices match your findings?
>>
>
> Not quite.
>
> Your proposal (A) to use extended attributes is essentially the same as I
> described under the description of a 'bread crumbs' model - i.e. keeping
> state around as we gradually explore the world through a redirect, and
> clearing this state (eating the breadcrumbs) for revocation. But while
> this
> can work out for a single redirect (and even then it's rather expensive),
> it will blow up pretty quickly when you start considering scenarios with
> multiple chained redirects, or cyclic redirects.

Yes, expense is a big issue, cyclic redirects however simply can not exist
given that every redirect adds a level of leaf node's that guarantee a DAG
for the primary file system.

> Your alternative (B) of supporting revocation but no further attenuation,
> is not one I had seriously considered. It turns revocable attenuation into
> a special case rather than something widely useful.
>
>
>>
>> Am I correct you believe to have found to allow for 4A like scenario's
>> without paying the performance or storage price for dynamically creating
>> and deleting the extended attributes throughout the tree?
>>
>
> Yes. It comes at the cost of keeping path information in the capability.
> Fortunately, I've also found a way to mitigate that.

Interesting. I don't quite follow your description. Could you sketch how,
given a redirect, we can do decomposition membrane operations without as
you state it adding breadcrumbs throughout the sub tree?

Lets say we have:

/cap/$alicecap/foo/bar/baz.txt

and a redirect (that alice can revoke)

/cap/$bobcap/alicedata -> /cap/sparsecap($alicecap/foo)


Now lets say bob wants carol to have:

/cap/$carolcap/bobsalicedata -> /cap/ROSPARSECAP($bobcap/alicedata/bar)

that bob would be able to revoke, and that would also get revoked when
alice revokes bob his redirect.

For reference the breadcrumb extended-attribute example would look
something like:

/cap/$bobcap/alicedata -> /redir/SPARSECAP($alicecap/foo:r1)
/cap/$carolcap/bobsalicedata -> /redir/ROSPARSECAP($alicecap/foo/bar:..+r1)

Where SPARSECAP and ROSPARSECAP could use something like:

  http://minorfs.wordpress.com/2014/03/21/rumpelstiltskin-and-his-children-part-2/

I would be really interested in using a less costly solution than the
above one (in fact the costliness is what keeps me from wanting to
actually implement a revocability membrane filesystem). Could you maybe
take me through the above scenario using your concepts?

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