Allow import of whole filesystem class hierarchy?
My company has a Zope server that has no editing rights for external persons - only employees have management permissions. We also have a company-specific hierarchy of several hundred Python modules that I'd like to access from Zope. Rather than modifying each and every module as per the instructions in the "Security" chapter of the ZDG, is there a way to say "allow the import of any module inside this part of $PYTHONPATH"? Oh, for those curious: part of the reason for moving code from Zope Python scripts and into filesystem code is that my company has officially adopted Python as our new development platform for new projects. I'm cranking out thousands of lines of code, and the Windows guys are tweaking it to run under IronPython. The end goal is to have a library of code that runs under Unix, Windows, Mac, or wherever else we might want to explore, and then to write frontends to that library in whatever seems appropriate to the task. For example, new web apps will be written with Zope calling those modules. New GUI apps will be written with Visual Studio calling those modules. Yay Zope and Python! You're what broke us away from vendor lock-in! -- Kirk Strauser Daycos
--On 24. Januar 2007 07:26:32 -0600 Kirk Strauser <kirk@daycos.com> wrote:
My company has a Zope server that has no editing rights for external persons - only employees have management permissions. We also have a company-specific hierarchy of several hundred Python modules that I'd like to access from Zope. Rather than modifying each and every module as per the instructions in the "Security" chapter of the ZDG, is there a way to say "allow the import of any module inside this part of $PYTHONPATH"?
<http://plone.org/documentation/faq/restricted-python-scripts> -aj
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kirk Strauser wrote:
My company has a Zope server that has no editing rights for external persons - only employees have management permissions. We also have a company-specific hierarchy of several hundred Python modules that I'd like to access from Zope. Rather than modifying each and every module as per the instructions in the "Security" chapter of the ZDG, is there a way to say "allow the import of any module inside this part of $PYTHONPATH"?
Oh, for those curious: part of the reason for moving code from Zope Python scripts and into filesystem code is that my company has officially adopted Python as our new development platform for new projects. I'm cranking out thousands of lines of code, and the Windows guys are tweaking it to run under IronPython. The end goal is to have a library of code that runs under Unix, Windows, Mac, or wherever else we might want to explore, and then to write frontends to that library in whatever seems appropriate to the task. For example, new web apps will be written with Zope calling those modules. New GUI apps will be written with Visual Studio calling those modules. Yay Zope and Python! You're what broke us away from vendor lock-in!
The most straighforward hack to do what you want would be to monkey-patch 'AccessControl.ZopeGuards.guarded_import', which is the function that does the current checking. Slightly less hackish would be to mutate the security policy, whose 'validate' method is responsible for checking the policy. By default, Zope uses the 'C' version of the security policy, which can't be monkey-patched. However, your *best* bet is to implement your Zope applications as filesystem-based products, rather than in "untrusted" code (Python scripts). At that point, the modules are easily importable. You can arrange for the filesystem products to expose any features which are needed (e.g., by PageTemplates). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFt4mT+gerLs4ltQ4RAlB8AJ9+KxyFBOIsoFyQ8XvA/NgAPqnXbgCglhA1 NX/zejgB/eJUi0N0SXBpdZk= =K3Qc -----END PGP SIGNATURE-----
--On 24. Januar 2007 11:30:11 -0500 Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Kirk Strauser wrote:
My company has a Zope server that has no editing rights for external persons - only employees have management permissions. We also have a company-specific hierarchy of several hundred Python modules that I'd like to access from Zope. Rather than modifying each and every module as per the instructions in the "Security" chapter of the ZDG, is there a way to say "allow the import of any module inside this part of $PYTHONPATH"?
Oh, for those curious: part of the reason for moving code from Zope Python scripts and into filesystem code is that my company has officially adopted Python as our new development platform for new projects. I'm cranking out thousands of lines of code, and the Windows guys are tweaking it to run under IronPython. The end goal is to have a library of code that runs under Unix, Windows, Mac, or wherever else we might want to explore, and then to write frontends to that library in whatever seems appropriate to the task. For example, new web apps will be written with Zope calling those modules. New GUI apps will be written with Visual Studio calling those modules. Yay Zope and Python! You're what broke us away from vendor lock-in!
The most straighforward hack to do what you want would be to monkey-patch 'AccessControl.ZopeGuards.guarded_import', which is the function that does the current checking. Slightly less hackish would be to mutate the security policy, whose 'validate' method is responsible for checking the policy. By default, Zope uses the 'C' version of the security policy, which can't be monkey-patched.
However, your *best* bet is to implement your Zope applications as filesystem-based products, rather than in "untrusted" code (Python scripts). At that point, the modules are easily importable. You can arrange for the filesystem products to expose any features which are needed (e.g., by PageTemplates).
TrustedExecutables are possibly a solution if you don't have much concerns about security issues. -aj
On Wednesday 24 January 2007 10:30 am, Tres Seaver wrote:
The most straighforward hack to do what you want would be to monkey-patch 'AccessControl.ZopeGuards.guarded_import', which is the function that does the current checking.
Before I start on such an adventure, what is the Python/Zope term for what I'm trying to do, specifically to allow the import of an entire module, including classes inside it, and methods inside those classes' objects?
However, your *best* bet is to implement your Zope applications as filesystem-based products, rather than in "untrusted" code (Python scripts). At that point, the modules are easily importable.
Maybe so, but I'm not looking forward to re-writing several years worth of production code. I was really hoping for a simple switch that told Zope to blanketly let me use a module and its contents. I'm still somewhat in disbelief that it's not there. -- Kirk Strauser Daycos
--On 24. Januar 2007 13:16:15 -0600 Kirk Strauser <kirk@daycos.com> wrote:
However, your *best* bet is to implement your Zope applications as filesystem-based products, rather than in "untrusted" code (Python scripts). At that point, the modules are easily importable.
Maybe so, but I'm not looking forward to re-writing several years worth of production code. I was really hoping for a simple switch that told Zope to blanketly let me use a module and its contents. I'm still somewhat in disbelief that it's not there.
Please read my last mail about TrustedExecutables. Try them out and check if TE fits your needs...then come back. -aj
Kirk Strauser wrote at 2007-1-24 13:16 -0600:
... Before I start on such an adventure, what is the Python/Zope term for what I'm trying to do, specifically to allow the import of an entire module, including classes inside it, and methods inside those classes' objects?
With "allow_module" you allow import of a (single) module and make all its content (on top level!) public (i.e. usable). With "allow_class", you make all its content (on top level) public. With "allow_type", you make a built in type usable in untrusted code. That's what you have as prepared tools. Adventures are necessary to get more of it.... -- Dieter
participants (4)
-
Andreas Jung -
Dieter Maurer -
Kirk Strauser -
Tres Seaver