> 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__ ? 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 func_closure 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 func_closure, it doesn't seem > like you really need to remove func_closure. 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 | [EMAIL PROTECTED] | +44 (0) 7809 569 369 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
