...

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