James William Pye schrieb:
> On Sat, Feb 25, 2006 at 01:21:34PM -0700, I wrote:
>
>>From what I have seen of zope's restricted python, it does, or can, force its
>>restrictions by checking bytecode. I imagine a simple PL sitting on top of the
>>untrusted varient that merely implements a custom validator that checks the
>>bytecode produced by the untrusted PL's validator. The language handler would
>>remain the same:
>
> [ugh, Correcting my assumptions...]
>
> Zope's RestrictedPython is a custom bytecode generator that compiles Python
> code specially, as opposed to a bytecode processor that validates against some
> rule set as I had thought for some (wishful? ;) reason. The bytecode then needs
The key point is: it replaces dangerous elements while it compiles the
bytecode - in theory you could also walk the tree after the python
bytecode compiler (not sure if it even works this way)
for example eval() open() file() import, ... are/can be replaced in this
step.
> to be executed in an special environment that then imposes some specified
> restrictions at runtime(I'm not really clear on all the details here as I
> am having a very difficult time finding documentation).
The special environment is there for the fine grained security only zope
would need in this case. (It protects object attributes individually
while maintaining acquisition and all that stuff)
> This doesn't mean that it couldn't be used. However, it does mean that some
> munging of the handler would be required(Something that I desired to avoid).
You should be able to use most of that technique in the stage where you
create the bytecode - just the step pl/plsql does too.
Regards
Tino