On Tue, Apr 12, 2016 at 01:08:36PM +1200, Greg Ewing wrote: > Jon Ribbens wrote: > >So far it looks like blocking "_*" and the frame object attributes > >appears to be sufficient. > > Even if your sandbox as it currently exists is secure, it's > only an extremely restricted subset.
I'm not sure what you think the restrictions are, but yes a highly restricted Python that was secure would be very useful sometimes. > You seem to be assuming that if your technique works so far, then it > can be extended to cover a larger subset, but I don't think that's > certain. No, I'm not assuming that. > One problem that's been raised is how to prevent untrusted > code from monkeypatching imported modules. Possibly that > could be addressed by giving the untrusted code a copy of > the module, Yes, that's what it does. > but I'm not entirely sure -- accidentally importing two copies of > the same source file is a well-known source of bugs, after all. I'm not sure what you mean by that. > A related, but more difficult problem is that if we allow > the untrusted code to import any pure-Python classes, it > will be able to monkeypatch them. So it seems like it will > need its own copy of those classes as well Yes, that's also what it does. > -- and having two copies of the same class around is *another* well > known source of bugs. I'm not sure what you mean by that either. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
