Re: how to extend a capability on a data source?
Rob Withers <[email protected]>
| Newsgroups | gmane.comp.capabilities.general |
|---|---|
| Message-ID | <[email protected]> |
Thanks for reminding me of the wiki. Isn’t data-flow built using message passing, typically? How is streaming different than message passing? What is quite interesting to me, is the general concept of being able to “track” and interact with distributed eventual computations. This includes many of the features you allude too, like revocability, membranes, audibility, as well as just promise sending itself. Having a continuation that reports the result back to the sender could also be considered in this category, perhaps. I have been working with kafka and hadoop, lately. Both are highly-available systems, with replication. How could “tracking” an eventual send be made highly-available? thank you, rob On Nov 2, 2013, at 6:11 AM, David Barbour <[email protected]> wrote: > Start with a simpler concept: revocable capability pattern. > > http://wiki.erights.org/wiki/Walnut/Secure_Distributed_Computing/Capability_Patterns#Revocable_Capabilities > > We can call this 'explicit' because we must explicitly call 'makeCapabilityRevokerPair', and we must explicitly track the revoker. If we didn't have the foresight to do this, we're out of luck (unless we stop our whole machine). We can call this 'stateful' because of how revocation is modeled: changing mutable state on a reference. > > The revocable capability pattern is easy to extend. For example, instead of just 'revoke', we could introduce methods that allow us to install auditors or switch the capability at a later time. Another extension to the revocable capability pattern is the membrane pattern, which is essentially a deeply recursive revocation pattern, which also touches any capabilities one shares through the revoker: > > http://wiki.erights.org/wiki/Walnut/Secure_Distributed_Computing/Capability_Patterns#Membranes > > It is worth noting that, by nature of being deeply recursive, membrane patterns are a lot more difficult to extend with auditing or other features in a sensible way. Anyhow, that's an explicit, stateful membrane. > > I do something very different here, which removes the need for explicit revokers and membranes, and is also much more expressive for precise auditing and so on. However, this is accomplished in part because I abandoned "message passing" as a basis for communication, and switched to a more streaming/dataflow model that implicitly maintains connectivity, like a spreadsheet for the real world. > > > > On Sat, Nov 2, 2013 at 2:08 AM, Rob Withers <[email protected]> wrote: > What is a stateful, explicit membrane and what does one look & feel like? > > thank you kindly, > rob > > On Nov 1, 2013, at 9:33 AM, Mark S. Miller <[email protected]> wrote: > >> Well, when you do. I've got a zillion questions, but they're not worth formulating until I can stare at an example ;). >> >> >> On Fri, Nov 1, 2013 at 7:12 AM, David Barbour <[email protected]> wrote: >> The implicit membrane doesn't look like a membrane. I suppose some Kerberos ticket-granting strategies might be a close analogy. Tickets expire, but in some cases can be renewed and replaced, with the expectation that users switch to the new ticket before the old one expires. In the same sense, distributed capabilities in an RDP system are periodically expired and replaced - with a little bit of overlap for smooth, latency-tolerant transitions. >> >> Anyhow, I don't have time at the moment to build a proper example. Sorry. >> >> >> >> On Fri, Nov 1, 2013 at 7:55 AM, Mark S. Miller <[email protected]> wrote: >> Hi David, what does this implicit membrane look like in your model? Could you post an example? >> >> >> On Fri, Nov 1, 2013 at 5:43 AM, David Barbour <[email protected]> wrote: >> I am developing a system where all capabilities grants are uniformly visible, revocable, auditable, attenuable. It is based on a reactive programming model: a capability must be continuously, declaratively granted. Conceptually, the old capability is continuously expired, and a new one continuously replaces it. Of course, I can't actually implement "continuous" revocation, but the implementation can approximate continuous revocation by replacing and expiring capabilities periodically or randomly or whenever changes are needed. >> >> A consequence is that capabilities in this model are not used as persistent values, and the risk of a temporary capability leak is mitigated. Explicit, stateful membranes don't seem to be necessary in this design, since the implicit membrane based on dataflow seems to cover all use-cases. However, user-defined security policies - i.e. the code that controls how the capabilities are distributed - can be persistent. >> >> Best, >> >> Dave >> >> On Fri, Nov 1, 2013 at 2:31 AM, William ML Leslie <[email protected]> wrote: >> On 1 November 2013 17:43, Rob Withers <[email protected]> wrote: >> > the widget isn’t as nearly important as the relationships one builds. >> >> Well, that's an interesting point. Has anyone got a service where >> users are creating their own membranes? Have any of you attempted to >> store user-defined membranes in a relational database? How is it >> done? >> >> -- >> William Leslie >> >> Notice: >> Likely much of this email is, by the nature of copyright, covered >> under copyright law. You absolutely may reproduce any part of it in >> accordance with the copyright law of the nation you are reading this >> in. Any attempt to deny you those rights would be illegal without >> prior contractual agreement. >> >> _______________________________________________ >> cap-talk mailing list >> [email protected] >> http://www.eros-os.org/mailman/listinfo/cap-talk >> >> >> _______________________________________________ >> cap-talk mailing list >> [email protected] >> http://www.eros-os.org/mailman/listinfo/cap-talk >> >> >> >> >> -- >> Cheers, >> --MarkM >> >> _______________________________________________ >> cap-talk mailing list >> [email protected] >> http://www.eros-os.org/mailman/listinfo/cap-talk >> >> >> >> _______________________________________________ >> cap-talk mailing list >> [email protected] >> http://www.eros-os.org/mailman/listinfo/cap-talk >> >> >> >> >> -- >> Cheers, >> --MarkM >> _______________________________________________ >> cap-talk mailing list >> [email protected] >> http://www.eros-os.org/mailman/listinfo/cap-talk > > > _______________________________________________ > cap-talk mailing list > [email protected] > http://www.eros-os.org/mailman/listinfo/cap-talk > > > _______________________________________________ > cap-talk mailing list > [email protected] > http://www.eros-os.org/mailman/listinfo/cap-talk _______________________________________________ cap-talk mailing list [email protected] http://www.eros-os.org/mailman/listinfo/cap-talk