Re: Redirects and Revocation in a Capability Filesystem

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.

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.

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