Constrain what can be accessed when eval'ing module search paths.
-----------------------------------------------------------------
Key: MODPYTHON-203
URL: http://issues.apache.org/jira/browse/MODPYTHON-203
Project: mod_python
Issue Type: Improvement
Components: core
Affects Versions: 3.2.10, 3.3
Reporter: Graham Dumpleton
Priority: Minor
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
