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. 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.
