Re: [Zope-dev] Trying to design a PythonMethod Product
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
Christopher Petrilli wrote: [replacing manipulating the AST with bytecodehacks]
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.
Is your stuff in C? It would probably be more straightforward to do something like bytecodehacks in C than it is manipulating any type of tree. And I think manipulating arrays in C can be a lot faster than manipulating a tree full of pointers. So a performance comparison would be indeed very interesting.
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.
It's definitely possible; as I mentioned before, look at the discussion on Python microthreads on comp.lang.python. Will Ware has implemented this, and it consists of loading a module, no hacking of the Python main engine itself. Of course that module *does* contain a hacked up version of the Python interpreter, so it raises maintainability concerns, but apparently the plan is to merge this in with the Stackless Python project, which seems to have at least a chance of making it into the main Python distribution.
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. [snip] 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.
What about doing it both? Make the code web managed but allow a way to edit it in the Python module way as well. Things like this are possible; XML Document for instance allows some manipulating of the XML as a Zope tree, but at the same time it represents itself as a plaintext document. But I'd agree with Chris here that doing it the Zope way first is the best way to go; and probably easiest.
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.
But of course, if by using the existing machinery it is improved, that's good. And often one can improve something existing better if one has tried to implement it by oneself first. So the thinking is at least not waisted. But I think we all agree on using the existing machinery as much as possible. Regards, Martijn
participants (2)
-
Christopher Petrilli -
Martijn Faassen