[Python-Dev] In defense of Capabilities [was: doc for new restricted execution design for Python]

[Brett Cannon]

On 7/7/06, Guido van Rossum <guido at python.org> wrote:
>
> On 7/7/06, Brett Cannon <brett at python.org> wrote:
> > I guess I am just not seeing where your approach is better than
> preventing
> > the constructor in 'file' and having open() return the 'file' object or
> > proxy object.  With your approach 'file' would be flagged, but with the
> > other you just put the same check in 'file's constructor.  With both you
> > would probably also want open() to be a factory function anyway.  So I
> don't
> > see where you gain simplicity or more security.  It seems like you are
> > pushing the check into the eval loop, but you still require the flagging
> of
> > objects as unsafe.  Going with the other two proposals you don't burden
> the
> > eval loop with the check but the objects that you would have flagged in
> the
> > first place.
> >
> > It just seems like we are pushing around the flagging of unsafe stuff
> and
> > that doesn't feel like it buys us much.
>
> At the risk of repeating someone's point or making no sense (I'm only
> following this with half an ear) I would like to point out that as
> long as there's C code involved, we can have the equivalent of private
> constructors in C++/Java. This means classes that cannot be
> constructed by calling the class from Python. C code has to use some
> other API to create an instance, bypassing this check. It seems
> reasonable to me, even if most popular types *can* be constructed.
> There are other types that have this property, e.g. list iterators.
> Try type(iter(list()))().


 Good point.  C code could circumvent the bit check by doing all of the work
behind the scenes without pushing the object on the stack.  But if the check
is in the C code for the object itself it is much harder to get around.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20060707/fa8a7838/attachment-0001.html