[Zope-dev] Trying to design a PythonMethod Product

[Christopher Petrilli]

>> Look at the expression machinery, it would be insane to duplicate security
>> already implemented, and frustrating to have two separate "paradigms" for
>> managing security.
>
> Surely!  This consists of DT_Util, VSEval, and gparser, yes?  As far as I
> can tell, these perform two tasks;  They screen out restricted names and
> guard selected operations.  You folks may want to seriously consider
> replacing gparser with something using bytecodehacks; Walking an AST is
> terribly opaque and complex compared to manipulating an EditableCode object.
> That's how I'm doing things, anyway, and I'll do my best to use the
> information and guard functions in DT_Util directly.  Hmm.  For that matter,
> I may try to generalize enough to offer a plug-in replacement for VSEval.

I would be curious of the performance difference as well.  We wrote our
stuff LONG before anyone had developed anything better, and it was heavily
optimized.  Even a 5-10% performance hit is probably unacceptable in DTML,
given it needs to be faster as it is, and adding additional overhead is
silly.  It would have to benefit Zope at some level above just making it
more "obvious" how an AST is walked... 99.999999999% of users will never see
it, nor should they want to.

>> Actually, we talked about just limiting the "instruction counter" so that
>> you could catch anything that was taking an excessively long period of
> time
>> to execute.  Say 1M byte-codes?  This avoids having to worry about
>> individual flow constructs.
>
> Sounds great!  How? :-)

I'll have to look, but I recall Jim explaining a way to do this, so I'm sure
it's possible.

>> > 7. Either disallow "global", or redirect access to globals into a
> controlled
>> > namespace.
>>
>> Look at management of namespaces in expressions.
>
> This part is proving to be fairly deep.  DTML objects require a client and
> mapping to operate on.  I want PythonMethods to be a*lot* like External
> Methods, with any number of parameters (including zero) and the option to
> pass '_' or 'REQUEST' explicitly.  Under this regime, global names can't
> refer to Zope namespace contents; So far, I've got them accessing a volatile
> private namespace.

Hehehe, namespaces are *very* deep indeed, and are one of the difficulties
in doing things that people think should be "easy".

Our goal was NOT to make "External Methods" internal, but rather to allow
more complex Python expression web enabled.  The former is a very dangerous
path to walk down from a security perspective.  In fact, in our "image" it
wouldn't even have a "def" statement, nor could you define classes, etc., it
was simply for encapsulating more complex logic.

> This has led me to extend my original idea.  I *really* dislike requiring a
> separate Zope object for every method in a module of external methods, and I
> think it would be even more annoying when the actual code is web-managed.
> Now I'm thinking of creating a PythonModule product, which could define and
> expose any number of functions and classes.  These would act like methods of
> the PythonModule.  Perhaps defining an object named 'default' (or
> 'index_html'? <bleah>) would allow the PM to be called/rendered directly.
> Now, all the objects in the PM would have a meaningful shared global
> namespace, just as if they were in a regular Python module.

I disagree strongly here.  An "method" is an object, and it might reside in
a container (which one might call a Module), but modules are namespaces, not
objects in the sense that you're using them.   I think your goals, while
admirable, are substantially large enough in scope to mire down the
implementation with additional chrome that may or may not be useful.  I'd
recommend getting something very basic done before attempting the Holy
Grail.

I very much think you should use the existing machinery, rather than
designing your own new... it's just more variables to examine when trying to
understand the isolation mechanisms.

Chris

--
| Christopher Petrilli        Python Powered        Digital Creations, Inc.
| petrilli@digicool.com                             http://www.digicool.com