Description of problem: line 2, in <module> import Image File "/usr/lib64/python2.6/site-packages/PIL/Image.py", line 45, in <module> __import__("FixTk") File "/usr/lib64/python2.6/lib-tk/FixTk.py", line 15, in <module> import ctypes File "/usr/lib64/python2.6/ctypes/__init__.py", line 546, in <module> CFUNCTYPE(c_int)(lambda: None) MemoryError Version-Release number of selected component (if applicable): python26-2.6.5-6.el5 libffi-3.0.5-1.el5 python26-imaging-1.1.7-4.el5 mod_wsgi-3.3-1 How reproducible: mount /tmp as noexec, create wsgi file to import Image Steps to Reproduce: 1. ??? 2. import Image 3. Actual results: receive MemoryError exception Expected results: no exception Additional info: This does not seem to happen outside of mod_wsgi. I am pretty sure it's because libffi wants to mmap a segment x or rx memory in /tmp, which is mounted noexec. Guessing here, outside of mod_wsgi the memory is attempted to map in HOME, and succeeds because the daemon user's homedir is writeable and executable. Inside mod_wsgi HOME is unset, so /tmp is used instead. It is a fairly common practice to mount /tmp noexec so someone smarter than me needs to do something here. Maybe a getent if HOME is unset inside libffi? Or maybe make mod_wsgi set HOME?
I've configured mod_wsgi to run in daemon mode. This forces app to run under specified uid/gid with it's own writable home. First, make runtime directory for unix sockets. It must be writable only by root (mod_wsgi docs warn against using /tmp) but accessible by others, so default logs directory won't do since it has o-x. # mkdir /var/run/mod_wsgi # restorecon /var/run/mod_wsgi /etc/httpd/conf.d/z.conf: (could be wsgi.conf as well) <IfModule wsgi_module> WSGISocketPrefix /var/run/mod_wsgi/wsgi WSGIDaemonProcess wsgi user=username group=username ...other settings here... WSGIProcessGroup wsgi </IfModule> And to solve final bit (assuming selinux is enabled): # setsebool -P httpd_tmp_exec 1 Worked for me on Fedora 15 with python 2.7.
Fedora EPEL 5 changed to end-of-life (EOL) status on 2017-03-31. Fedora EPEL 5 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora or Fedora EPEL, please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.