[cap-talk] revoking capabilities yet maintain structure/functionality, garbage collection

[Sandro Magi]

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
> time.  

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.

http://host/userGuid/objectGuid

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?

Sandro

> What Web-Calculus provides is a way to spread your data structures and 
> methods
> all over the network.  Not that many people would do that, but I can see 
> some
> programmers go ape-wild without paying attention to POLA, given fast enough
> networks.  How do you stop misuse of something that should be used 
> carefully?
> 
> Where does POLA meet P2P?
> 
> John
> 
> 
> 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 
>>> unique
>>> 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 
>> particular
>> Swiss Number) is no longer valid for access.  When an object is
>> destroyed (e.g. to recover resources) it is "garbage collected" as you 
>> say.
>>
>>> Capabilities sound a lot like some forms of mental illness, where you
>>> can lose track of portions of your personality or memory.  But maybe 
>>> that
>>> 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 
>> network
>> capabilities like YURLs or widewords.  If you destroy a soft link you 
>> invalidate
>> 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 
>> permission
>> 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
>> http://www.eros-os.org/mailman/listinfo/cap-talk
>>
> 
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk