On 24 March 2010 20:59, Graham Dumpleton <[email protected]> wrote:
> On 24 March 2010 17:17, Deron Meranda <[email protected]> wrote:
>> On Wed, Mar 24, 2010 at 1:44 AM, Graham Dumpleton
>> <[email protected]> wrote:
>>> As such, it perhaps should be allowed in .htaccess files and allowing
>>> that is pretty simple to do. Just change:
>>>
>>> AP_INIT_RAW_ARGS("WSGIHandlerScript", wsgi_add_handler_script,
>>> NULL, ACCESS_CONF|RSRC_CONF, "Location of WSGI handler script
>>> file."),
>>>
>>> to:
>>>
>>> AP_INIT_RAW_ARGS("WSGIHandlerScript", wsgi_add_handler_script,
>>> NULL, OR_FILEINFO, "Location of WSGI handler script file."),
>>>
>>> and let me know if any problems come up with using it in .htaccess files.
>>
>> So far, that seems to work well. Though I haven't
>> really tested it very hard yet.
>
> The problem is that adding that change creates a security hole.
>
> This is because the WSGIHandlerScript accepts process-group option.
> Thus if this was a shared system with mod_wsgi daemon process groups
> run as different users then you would be able to have your code run in
> the context of any of those process groups which weren't restricted
> from you and so execute code as another user. Restrictions on process
> groups one can delegate to isn't a default and has to be set up, so
> typical setup would have this problem.
>
> The solution would be to disallow process-group option if directive is
> used in a .htaccess file.
>
> Note that application-group is also usable, but all it is going to do
> is to allow you run in context of a different interpreter of what ever
> process application would run in. This isn't ideal either, but just
> realised that allowed WSGIAuth???Script directive in .htaccess with
> Auth is allowed in .htaccess has already opened up that can of worms.
>
> It isn't that allowing application-group is itself a security hole
> because as running different users code in same process as same user
> already is a security problem and should never be used in shared
> hosting. Specifically code could already access user data for other
> applications or modify writable files by Apache user used by others
> user code. The application-group option does make it easier to
> access/modify in process running Python, but this was already
> possible, albeit much harder, by loading a custom C extension module
> that use Python C APIs to inject code/calls into another sub
> interpreter.
>
> So, application-group can be lived with, but process-group definitely
> cannot. This would need to be addressed if were to make that change.
A couple more things I forgot to mention. From memory, unless you
override application-group with WSGIHandlerScript, or set
WSGIApplicationGroup directive, although the one WSGI script for
handling requests, a new sub interpreter is created corresponding to
each unique resource matched.
You should therefore say something like:
WSGIHandlerScript my-wsgi-handler /some/path/application.wsgi
application-group=%{GLOBAL}
or:
WSGIHandlerScript my-wsgi-handler /some/path/application.wsgi
and set:
WSGIApplicationGroup %{GLOBAL}
in context for where all resources are.
This will force use of same sub interpreter in process.
Also, you can probably make your configuration simpler or more precise
by still using mod_rewrite using something like:
WSGIHandlerScript my-wsgi-handler /some/path/application.wsgi
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule .* - [H=my-wsgi-handler]
In other words, any request that doesn't match a file based resource
should be handled by handler of type my-wsgi-handler.
Note, I have tested this, so if you try it let me know outcome.
This will save you having to exclude by extension and allows non
existent files of those extensions to still potentially be served by
Python web application so it could generate them rather than outright
returning a 404.
This would allow you for example to use file system as cache and if
file not present pass through to web application to generate it and
return via wsgi.file_wrapper first time. On subsequent times could
pick up file you write to cache directory when generated. Just need to
be careful to write file under different name and move it into place
so is complete and partial file not picked up by another request
arriving while first is generating the file.
Graham
--
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=en.
