Stop Python directives being used in .htaccess files.
-----------------------------------------------------
Key: MODPYTHON-183
URL: http://issues.apache.org/jira/browse/MODPYTHON-183
Project: mod_python
Issue Type: New Feature
Components: core
Reporter: Graham Dumpleton
When changes to support use of wildcards in conjunction with the Directory
directive (as described in MODPYTHON-63), and use of DirectoryMatch or ~ with
the Directory directive are also supported, it will be possible to say
something like:
<Directory /home/*/public_html>
AddHandler mod_python .py
PythonHandler mod_python.publisher
PythonInterpPerDirective On
PythonDebug on
</Directory>
Such a setup will allow for a form of automatic mass hosting where it is not
necessary to specify the directives for every user manually. Further, the use
of the PythonInterpPerDirective directive will mean that each users code is
isolated within their own Python interpreter instance. How well this will scale
is another issue, but it will be possible to do.
The problem with this is that if the user is still able to make use of a
.htaccess file, then it is possible for them to override these directives to
make it do something entirely different, or even override which Python
interpreter instance is used and force their handlers to run within the context
of another users Python interpreter. If an administrator wants to be able to
force that things are done in a specific way, but still allow some level of
control by a user using a .htaccess file, then a way is needed of specifying
from the main Apache configuration file that a user .htaccess file is not
allowed to override the behaviour of different aspects of mod_python.
This could be achieved by implementing a new directive called
PythonAllowOverride. The simplest argument to this directive would be:
PythonAllowOverride None
By specifying this in the main Apache configuration file, it would prevent the
use of any mod_python related directives in .htaccess files.
In addition, since mod_python allows everything to be overridden by default
anyway, one could use a subtractive approach to allow specific features to be
prohibited from being overridden in a .htaccess file. For example:
PythonAllowOverride -Interpreter
This would have the affect of prohibiting the use of PythonInterpreter,
PythonInterpPerDirectory and PythonInterpPerDirective.
One could also prohibit any handlers being specified in a .htaccess file using:
PythonAllowOverride -Handlers
Rather than prohibiting all handlers, one could allow each to be enumerated.
PythonAllowOverride -AccessHandler -AuthenHandler -AuthzHandler
This particular case would be quite important, as at the moment there is
potential for a user to override a site wide security scheme by specifying
their own authentication handler that replaces the site wide security and just
lets everyone in.
Allowing a user to use the PythonOption directive could also be prohibited.
PythonAllowOverride -Options
Not allowing them to specify any options at all though might be a bit
draconian, but you might want to at least prohibit them from setting certain
options. For example, when mod_python is fixed so as to always use a
'mod_python.' prefix for its own options, you might specify:
PythonAllowOverride -Options=mod_python.*
By doing this, you would prohibit a user for overriding options related to
sessions for example and thereby screwing things up. The syntax for this one
may need to be different, or even perhaps supported by a separate directive for
this purpose.
It should be noted though, that a users handler could still set options from
within the handler itself, but the important thing is that no options would
have played havoc with handlers for earlier phases such as authentication
phases in cases where allowing a user to specify a handler for the earlier
phase was prohibited.
Other things that could be selectively prohibit are:
PythonAllowOverride -Path
PythonAllowOverride -AutoReload
PythonAllowOverride -Debug
All in all, something like this directive is needed to make mod_python more
attractive in environments where an extra level of control is required such as
shared hosting or even company systems where users are allowed to specify their
own web pages/handlers.
--
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
