Ka-Ping Yee wrote: > Wow, how did this topic end up crossing over to this list while > i wasn't looking? :0 > > Ben Laurie wrote: > >>I'll admit to being that person. A capability is, in essence, an >>opaque bound method. Of course, for them to be much use, you >>want the system to provide some other stuff, like not being able >>to recreate capabilities (i.e. you get hold of them from on >>high, and that's the _only_ way to get them). > > > Jeremy Hylton wrote: > >>That seems like a funny defintion of a capability. > > > A better definition of "capabilitiy" is "object reference". > > "Bound method" isn't enough, because a capability should be able > to have state, and your system should have the flexibility to > represent capabilities that share state with other capabilities, > or ones that don't. The simple, straightforward way to model this > is to just equate the word "capability" with "object reference". You can it that way, too, but it strikes me as more unwieldy in practice. A bound method also has state because it is, of course, bound to an object reference, so I find that a more elegant way to do it. >>A capability system must have some rules for creating and copying >>capabilities, but there is more than one way to realize those rules in >>a programming language. > > > I suppose there could be, but there is really only one obvious way: > creating a capability is equivalent to creating an object -- > which you can only do if you hold the constructor. A capability > is copied into another object (for the security folks, "object" > == "protection domain") when it is transmitted as an argument to a > method call. > > To build a capability system, all you need to do is to constrain > the transfer of object references such that they can only be > transmitted along other object references. That's all. > > The problem for Python, as Jeremy explained, is that there are so > many other ways of crawling into objects and pulling out bits of > their internals. > > Off the top of my head, i only see two things that would have to > be fixed to turn Python into a capability-secure system: > > 1. Access to each object is limited to its declared exposed > interface; no introspection allowed. > > 2. No global namespace of modules (sys.modules etc.). > > If there is willingness to consider a "secure mode" for Python > in which these two things are enforced, i would be interested > in making it happen. I believe you just described rexec. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4