From: "Ben Laurie" <ben@algroup.co.uk> > Guido van Rossum wrote: > > [Moving a discussion about capabilities to where it arguably belongs] > > > > [Ben Laurie] > > > >>The point about capabilities is that mere possession of a capability is > >>all that is required to exercise it. If you start adding security > >>checkers to them, then you don't have capabilities anymore. But the > >>point is somewhat deeper that than - given capabilities, you can > >>implement proxies without requiring any more infrastructure - you can > >>also implement security schemes that don't really correspond to any kind > >>of security checking at all (ok, you can probably find some convoluted > >>way to achieve the same effect, but I'll bet it comes down to having > >>tokens that correspond to proxies, and security checkers that allow you > >>to proceed if you have the appropriate token - in other words, > >>capabilities, but very hard to use). > >> > >>So, it seems to me, its simpler and more powerful to start with > >>capabilities and build proxies on top of them (or whatever alternate > >>scheme you want to build). > >> > >>Once more, my apologies for not just getting straight to the point. > >> > >>BTW, if you would like to explain why you don't think bound methods are > >>the way to go on python-dev, I'd love to hear it. > > > > > > It seems to e a matter of convenience. Often objects have many > > methods to which you want to provide access as a group. E.g. I might > > have a service configuration registry object. The object behaves > > roughly like a dictionary. A certain user may be given read-only > > access to the registry. Using capabilities, I would have to hand her > > a bunch of capabilities for various methods: __getitem__, has_key, > > get, keys, items, values, and many more. Using proxies I can simply > > give her a read-only proxy for the object. So proxies are more > > powerful. > > > > Before you start saying that we should use capabilities as the more > > fundamental mechanism and build proxies on top of that: as you point > > out, we already have an equivalent more fundamental mechanism, bound > > methods, which is equivalent to capabilities. It's just that raw > > capabilities aren't very usable, so one way or another we've got to > > build something on top of that. > > I'm not trying to persuade you that capabilities are better than > proxies. I'd prefer to build on them, and it seems you'd prefer to do it > another way. That's fine with me - my goal is to make capabilities both > possible and easily usable in Python, not to persuade everyone to use > them (yet ;-). > > Bound methods are not capabilities unless they are secured. It seems the > correct way to do this is to use restricted execution, and perhaps some > other tricks. What I am trying to nail down is exactly what needs doing > to get us from where we are now to where capabilities actually work. As > I understand it, what is needed is: > > a) Fix restricted execution, which is in a state of disrepair > > b) Override import, open (and other stuff? what?) > > c) Wrap or replace some of the existing libraries, certify that others > are "safe" > > It looks to me like a and b are shared with proxies, and c would be > different, by definition. Is there anything else? Am I on the wrong track? there is a difference: proxies cover indipendently much of the holes in restricted execution ... about restricted execution: - the way a new frame acquires the default built-ins vs. installed resticted bult-ins is likely correct but needs auditing; e.g. the last problem fixed related to this was: http://python.org/sf/577530 - under restricted execution some operation, in particular reflective ops ought to be prohibited, the code that implements this is scattered and/because this operations share the same execution paths with "normal" ops; so the first thing is enumerate all that should be prohibited, or devise an approach to security that can work with just a minimal set of guarantees (disabled ops and/or encapsulated objects) These were e.g. identified "problems": http://mail.python.org/pipermail/python-dev/2002-December/031160.html http://mail.python.org/pipermail/python-dev/2003-January/031851.html
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