[Zope-dev] Trying to design a PythonMethod Product

[Evan Simpson]

From: Christopher Petrilli <petrilli@digicool.com>
> I'll make some comments since we've tossed this around ENORMOUSLY in house
> and just haven't had the time to write it.  It's really not that hard I
> think, but you do need to take into account some issues.

I have working code going already, but I'm cleaning it up for general
consumption.  Any help getting the issues right is greatly appreciated.

> 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.

> > 4. Restrict "import" to modules/packages found in a particular location,
so
> > that 'safe' modules can be used.
>
> Take a look at rexec for this.

I have, and may use some bits of it.  Should we allow import of standard
modules, or even Extensions modules?  I'm leery of that, and lean toward
requiring explicitly exposing selected modules to import.  Heck, I may even
have 'import' bring in names from the Zope object hierarchy instead of
external files!

> 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? :-)

> Not sure how I like this honestly.  I'd probably just bind
sys.stdout.write
> to something new, that should cause print to work correctly.

I've got this part working to my satisfaction already.

> > 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.

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.

So far, I've got restricted assignment, print interception (and retrieval),
'del' and 'exec' blocking, a safe global namespace, and I'm comfortable with
mucking about in bytecodes.  Import handling and operator guards should be
straighforward (once I know what import should *do* <wink>).

Keep those ideas rolling,
Evan Simpson