[Python-Dev] object capability; func_closure; subclasses (original) (raw)
tav tav at espians.com
Thu Jun 28 14:09:01 CEST 2007
- Previous message: [Python-Dev] object capability; func_closure; __subclasses__
- Next message: [Python-Dev] object capability; func_closure; __subclasses__
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
You know, I find it particularly interesting that, as far as I can tell, nobody who proposes making changes to the Python language to add security, ever seems to offer any comparison or contrast of their approaches to Zope's -- which doesn't require any changes to the language. :)
Whilst it is definitely possible to build up a object capability system with a pruned down version of Zope 3's proxy + checker mechanism, it ends up in a system which is quite performance intensive. All those proxies being wrapped/unwrapped/checked...
In contrast, the mechanism I am looking at here simply requires moving just 2 attributes out of the core builtins...
Quite cheap, simple and effective, no?
Well, you're missing a simpler approach to protecting functions, anyway. The 'call' attribute of functions is still callable, but doesn't provide any access to funcclosure, funccode, etc. I believe this trick also works for bound method objects.
Whilst that would have been a nice trick, what about call.self ?
Or, setting call.doc ?
I suspect that you could also use ctypes to remove or alter the type.subclasses member, though I suppose you might not consider that to be "pure" Python any more. However, if you use a definition of pure that allows for stdlib modules, then perhaps it works. :)
Ah, thanks! Will look into that.
I wouldn't object (no pun intended) to moving the type.subclasses method to say, the 'new' or 'gc' modules, since you wouldn't want to make those available to restricted code, but then they'd still be available for folks who need/want them. 'gc' has similar capabilities (again no pun intended) anyway.
Ah, that's a great idea!
However, ISTM that this should be a 3.0 change rather than a 2.x one, even so. With regard to the funcclosure thing, I'd actually like to make it writable as well as readable, and I don't mean just to change the contents of the cells. But, since you can use .call to make a capability without access to funcclosure, it doesn't seem like you really need to remove funcclosure.
I don't object to making func_closure writable either. In fact, as someone who has been following your work on generic functions from way before RuleDispatch, I really want to see PEP 3124 in 3.0
But, all I am asking for is to not expose func_closure (and perhaps
some of the other func_*) as members of FunctionType -- isn't it
possible to add functionality to the new
module which would allow
one to read/write func_closure?
-- love, tav founder and ceo, esp metanational llp
plex:espians/tav | tav at espians.com | +44 (0) 7809 569 369
- Previous message: [Python-Dev] object capability; func_closure; __subclasses__
- Next message: [Python-Dev] object capability; func_closure; __subclasses__
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]