Details
-
Improvement
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
3.3.x, 3.2.10
-
None
-
None
Description
When one uses PythonPath it is possible to access sys.path so that the path can be extended rather than replaced. That sys.path is accessible is merely a result of the fact that the eval() performed on the value of PythonPath is done without restricting the globals/locals and so it picks up the environment from the context in which the eval() is performed. As it happens, the module doing this has imported the 'sys' module and therefore it works.
The problem is that that module imports other stuff and also holds lots of internal data and functions. All of this data and the functions can also be accessed. For starters, the globals/locals of the eval should possibly be constrained to only allow reference to sys.path and nothing else.
Beyond that, we might consider whether access should be provided to other stuff which might be relevant in dynamically constructing a module search path. For example, should stuff like 'apache.main_server' be accessible along with stuff like 'os.path'. This would allow something like:
PythonPath "sys.path+[os.path.join(apache.main_server.get_options()['MYAPPROOT'],'modules')]"
Or is this just asking for trouble?
At the least, should constrain access to just sys.path when evaling PythonPath.
In a similar way, also in 3.3 now have mod_python.importer.path. This path should never reference sys.path, yet it is accessible when the eval() is performed. This should be constrained so that sys.path is not accessible at all. There might be other stuff though that we might want to allow access to, although one can already use '~/' prefix in the importer path to reference stuff relative to handler root, so possibly less call for it.