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