Details
-
New Feature
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
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.