[cap-talk] revoking capabilities
yet maintain structure/functionality, garbage collection
smagi at naasking.homeip.net
Fri Jan 13 10:32:40 EST 2006
John Carlson wrote:
> I don't think I am communicating. Say you have a highly linked set of
> web documents.
> You share a read/write capability on the set of documents with a
> person. Later, you
> decide that you want to revoke that person's right to access the
> documents. We have
> revocation for a single object, but what do you do if the object is
> really a bunch of links,
> all with YURLs? The person could jump into any place in the set. You
> would have
> to step through the whole set of documents, revoking every single one of
> them. It's
> not just "let's revoke this single thing." Say a person was placed on
> temporary leave.
> You would have to revoke all the documents, and then bring them back at
> a later
Like most information systems, ease of modification is dependent on how
you organize it. A given YURL could have two components, a user guid as
a 'directory' component of the path, and a guid identifying the object.
Just rename the user guid and all of that "user's" capabilities are
effectively revoked. It's a fairly straightforward technique that you
can use even if you're just working in the filesystem with documents.
For a web of objects, as in the web-calculus, Jed's approach is better.
> Are you saying that there is something about a set of objects
> represented by YURLs
> that make them particularly easy to revoke ALL of them? We're in a
> hyper world now,
> of object oriented programming with extremely small objects, not some
> document based
> system. Perhaps document based systems are all that YURLs are good
> for? I am looking
> for a fine grained solution.
How more fine-grained can you get than revoking individual YURLs?
> What Web-Calculus provides is a way to spread your data structures and
> all over the network. Not that many people would do that, but I can see
> programmers go ape-wild without paying attention to POLA, given fast enough
> networks. How do you stop misuse of something that should be used
> Where does POLA meet P2P?
> Jed at Webstart wrote:
>> At 09:05 AM 1/12/2006, John Carlson wrote:
>>> Here's some perhaps simple questions:
>>> So what technique is used to revoke capabilities, yet maintain the
>>> structure behind
>>> the revoked capability? For example, you could revoke a login
>>> capability, yet
>>> the file structure owned by that login capability could remain
>>> (possibly for
>>> forensics). How do you do this when capabilities of sub pieces can be
>>> communicated, like with YURLs? How do you revoke capabilities to the
>>> whole structure, yet maintain the structure? Do you have to have both a
>>> revocable capability and a structure (true) capability for everything
>>> on your website?
>>> Is this really just the ability to create deep copies of
>>> capabilities, and keep
>>> the originals in a safe place? How do you do this with Waterken? Do
>>> you just keep on handing out new capabilities, so each person gets a
>>> capability for objects returned from methods, even when the object
>>> returned is a singleton?
>> I think the basic answer is that there's a distinction between revoking a
>> capability (removing a permission) and destroying an object. Both are
>> possible and are independent operations. When considered from the
>> servers viewpoint this is quite simple. When a capability is revoked
>> the server notes that a particular reference (e.g. with YURLs a
>> Swiss Number) is no longer valid for access. When an object is
>> destroyed (e.g. to recover resources) it is "garbage collected" as you
>>> Capabilities sound a lot like some forms of mental illness, where you
>>> can lose track of portions of your personality or memory. But maybe
>>> really is security. For me, that sounds disturbing.
>>> What is the garbage collection capability? When do we use it?
>> This ties a bit back to the famous "lost object" problem that I tried to
>> start a new discussion on some time back. The answer is that
>> resources are recycled (objects destroyed) when there is a need
>> to recover the resources. You look at your bill and you say, "I'm
>> paying for what?!?" Then you look through your stuff and you say,
>> "I don't need that any more, or that, or that ...". You destroy them.
>> If anybody has an outstanding reference (with permission) to those
>> destroyed objects - well, too bad.
>> In "hierarchical" file systems (e.g. Unix, Windows, etc.) there is often
>> some confusion between destroying objects and removing names/references
>> (e.g. soft links) because the only way one has to destroy a resource
>> is to
>> remove it's "name" - what one hopes is the one true name. The situation
>> is really pretty similar to dealing with capabilities - especially
>> capabilities like YURLs or widewords. If you destroy a soft link you
>> a reference. If you destroy the base name in the hierarchy you
>> destroy the
>> object and invalidate any outstanding soft links. An important
>> difference with
>> capabilities, however, is that a capability "link" carries with it
>> to access the object - unlike a soft link that is truly just a name.
>> --Jed http://www.webstart.com/jed/
>> cap-talk mailing list
>> cap-talk at mail.eros-os.org
> cap-talk mailing list
> cap-talk at mail.eros-os.org
More information about the cap-talk