Re: [Python-Dev] object capability; func_closure; __subclasses__
At 01:09 PM 6/28/2007 +0100, tav wrote:
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 func_closure, func_code, etc. I believe this trick also works for bound method objects.
Whilst that would have been a nice trick, what about __call__.__self__ ?
Well, there's no __self__ in 2.3 or 2.4; I guess that was added in 2.5. Darn.
Or, setting __call__.__doc__ ?
What does that do?
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.
If it works, you could probably do the same thing to remove __call__.__self__.
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?
In 3.0, I don't mind if the access method moves, I just want to keep the access. OTOH, I don't really care about __call__.__self__, since I got along fine without it in 2.3/2.4 and didn't know it had been added in 2.5. :)
participants (2)
-
Phillip J. Eby
-
tav