[Python-Dev] object capability; func_closure; __subclasses__

[tav]

> 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 | tav at espians.com | +44 (0) 7809 569 369