Sorry loosing context in replying without quoting, but too many posts to try and individually address things as a response to each. Anyway, I will try and highlight some points I think are relevant.
1. A compiled bytecode .pyc file (default on UNIX), or .pyo (default on Windows I think), will be created the first time that a module is imported. In order to write that file, the user the code is running as must have write permission to the directory where the .py file exists. When running under Apache/mod_wsgi, unless you setup things explicitly to be otherwise, code will normally run as a special Apache user which will not have write access to the directories where the code files are. 2. For security reasons, even where you override what user code runs as, it would not be a good idea to allow writing to code directories as a flaw in your software which allows a remote user to execute arbitrary code would allow them to modify the on disk code of your application and plant code which would survive a process restart. Thus, always a good idea to have applications run as a different user, be that the Apache user, or another distinct user for just that application. Either way, shouldn't have write access to directories where code exists, even for writing .pyc/.pyo files as they too could be manipulated. The only places an application should have write access to are file upload directories and possibly other data directories if using file based database such a SQLite etc. 3. Although ideally one would block write access to all places that code could be placed so as to avoid security problems, egg cache directories present an interesting problem. The first is where an application expects to be able to unpack eggs when the application actually runs. Obviously for these it is going to expect write access, but then allows stuff their to be rewritten if your application is breached. For highest level of security, the egg cache location shouldn't even be writable and dynamic unpacking of eggs would be disabled somehow. This should possibly be the case even if you do not use eggs. If application is breached, it could still dynamically change egg cache location, but that is only going to apply for the life of that process provided that it wasn't able to write code anywhere to make it permanent. Anyway, if eggs are being used, then you should aim to have them all unpacked and already in existence before starting application and for egg cache to not be writable. 4. Even if .pyc/.pyo files could be written, this is probably only going to apply to your own code. Any Python code installed into standard Python installation will already have .pyc/.pyo files and not likely writable anyway. Even if you use virtual environments, and installed modules there, they also would normally have .pyc/.pyo files. Overall therefore, the bulk of code, which is going to be outside of your application normally anyway, is already going to have .pyc/.pyo files. That is therefore where the benefit will come from, not so much your possibly smaller amount of code. Thus, is questionable whether you would get much benefit from having .pyc/.pyo files for own code. 5. Having .pyc/.pyo files for your own code, which can change over time, can also cause problems. The issue here can be where if you ran Django development server and it wrote .pyc files. If then for some reasons you decided to revert a file and restore it from source control and then immediately went to run code, if the restored .py file had older modification date than the .pyc file, it would use the .pyc file in preference to the changed .py file. In some respects it would be better, especially during development, that you block generation of .pyc files to stop these sorts of problems. This can be done using an environment variable if using command line Python 2.6 or later. There is no way of disabling .pyc generation if using Apache/mod_wsgi through configuration even were the user to have write access to directories. Either way, if you really want .pyc/.pyo files, better when deploying to a production system to remove all existing files an regenerate with py_compile as user who does has write access, but then run application as user who doesn't. Do note though that byte coming the WSGI script file, even if it has a .py extension, shouldn't be done. This is because it isn't used and the .pyc file if in normal Apache document directory then might be downloadable as a static file. 6. The .pyc/.pyo files are only going to be of benefit the first time the module is imported. Because the whole point of Apache/mod_wsgi is to host long running processes, it only generally helps at process startup and not after that. Even that is not strictly true as mod_wsgi by default lazily loads the WSGI script file. This means loading occurs on first request to the application normally. You can use WSGIImportScript to force WSGI script to be preloaded on process startup and so loading wouldn't delay first request as much, but for some frameworks even that doesn't help. In Django for instance, it lazily loads most of the user code only when request arrives which requires it. 7. WSGIPythonOptimize can be used to enable generation of .pyo files and greater levels of optimisation on UNIX systems, but benefit of doing this is likely minimal as far as .pyo file loading goes. This relates to (6) above in that in the greater context of how long the process would normally live for, the quicker load times would be inconsequential. Enabling level 2 optimisation, ie., most aggressive, is also not a good idea as although it disables asserts, it also disables doc strings and certain Python modules rely on using information in doc strings. Disabling doc strings will therefore causes certain Python modules to fail and stop working. Conclusion. Overall I don't think there is much benefit from relying on .pyc/.pyo file loading. If you really want it, use py_compile to pre build them, do not rely on application having write access to create them. Having that write access in order to create them also reduces security of application. Hopefully that answers all the questions and more. If want clarification, or think I mischaracterised something, let me know. 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 -~----------~----~----~----~------~----~------~--~---
