Bug 495780

I'm not sure about this.  How is mod_wsgi using that directory?

Here's how I believe it works, I'm no httpd or mod_wsgi expert though:

mod_wsgi needs a unix domain socket when used in the 'daemon' mode, which is apparently the way to get best performance on a *nix platform. It uses the socket to 'communicate between the Apache child processes and the daemon processes'. See http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGISocketPrefix

I believe the main Apache process, which is run as root:root, creates the socket when Apache is started, so it can be created to a directory where only root has access. But when the WSGI application is used, the Apache child processes and the mod_wsgi daemon processes are running as apache:apache. Thus, the socket file needs to be in a directory where the apache user has at least read permissions. On previous Fedora/EL versions /etc/httpd/run, pointing to /var/run, has been a good choice, even the mod_wsgi tutorials recommend using it. Now with Fedora 11 this doesn't work anymore and I presume some existing mod_wsgi setups on Fedora 9 and 10 are going to break when upgraded.

This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

*** Bug 521233 has been marked as a duplicate of this bug. ***

(In reply to comment #1)
> I'm not sure about this.  How is mod_wsgi using that directory?  

I confirm the bug in Fedora 12 beta. Posted in devel list:

https://www.redhat.com/archives/fedora-devel-list/2009-October/msg01334.html

Also some comments from the mod_wsgi developer:

http://groups.google.com/group/modwsgi/browse_thread/thread/c5f5abc122088478

So the basics of those threads are:

* Apache modules that need to create socket files default to using the   DEFAULT_REL_RUNTIMEDIR.  This includes at least mod_wsgi, mod_cgid, and mod_fcgid.

* DEFAULT_REL_RUNTIMEDIR was changed from /var/run to /var/run/httpd (presumably for selinux).

* The permissions of /var/run/httpd (root:root, 0700) allow apache to create its socket file on startup but after that apache drops privleges and none of the modules are able to create files there.

It seems like there's a few ways to address this:

* Change the owner of the directory to apache, permissions remain 0700.
* Change the group to apache and change permissions to 0770.

Note, to also address Bug #521233, you need to give permission for others to read the directory so permissions would need to be 0755 or 0775 respectively.

Looking at /var/run on my system, only three services are usable only by root: sudo mdadm httpd.  Of these, sudo and mdadm run as root so they don't have permission problems.  Only apache isn't able to use its /var/run/ directory after startup.

Created attachment 366661 [details]
Allow running apache to use the statedir

Here's a patch to the rpm spec file to let apache use the statedir after startup.
The permissions on the /var/run/httpd directory match /var/lib/dav and /var/cache/mod_proxy using this.

Note that this is enough for mod_wsgi, mod_fcgi, etc but it does not solve bug #521233.  For that, you need to change permissions to 0755 like this:

+%attr(0755,apache,apache) %dir %{_localstatedir}/run/httpd

However, bug #521233 could also be solved by printing that the user does not have permission to read apache's pid file.  Figuring that out should not hold up fixing this for mod_wsgi, mod_fcgi, etc.

In response to #6 above.

"""* DEFAULT_REL_RUNTIMEDIR was changed from /var/run to /var/run/httpd
(presumably for selinux)."""

From what I have seen it has not changed. It still references the logs directory but the logs directory permissions were set to 0700 so not readable to apache user.

If it had been changed then it wouldn't be necessary to set:

  WSGISocketPrefix run/wsgi

but it is.

Problem as described now is that run directory also locked down to be 0700 when this workaround done, so that fails as well.

"""* The permissions of /var/run/httpd (root:root, 0700) allow apache to create
its socket file on startup but after that apache drops privleges and none of
the modules are able to create files there."""

The modules aren't trying to 'create files there' after having drop to apache user. They are just trying to read the files that were already created as root user from Apache parent process before server child processes were forked and privileges dropped to apache user.

"""It seems like there's a few ways to address this:

* Change the owner of the directory to apache, permissions remain 0700.
* Change the group to apache and change permissions to 0770."""

Apache modules when running as apache user shouldn't be trying to write to that directory. From what I have seen they only ever need read access to access UNIX socket files and standard ASF permissions on that directory ensure that is the case. You do not want to make the directory writable to Apache user as that will introduce a potential security hole for mod_wsgi. This is because server child process running as Apache user would be able to rename and replace the UNIX socket files that were created in that directory by Apache parent process when running as root and get access to information that would allow one to compromise mod_wsgi security related to daemon mode.

In other words, the whole point is that the UNIX sockets are created in root owned directory and that apache user can only read stuff, not write it.

In summary, DO NOT MAKE THE DIRECTORY WRITABLE TO APACHE USER, ONLY READABLE. If you release it such that it is writable, then you will need to follow that up with a security advisory telling people how you have just partly compromised their system.

Created attachment 366741 [details]
Allow running apache to read the statedir

Thanks for joining in Graham!

New patch that allows apache to read the statedir after startup but not write.  Once again, note that it doesn't solve the other bug.  For that, you'd either need to set the directory perms 0755 or modify the init script to tell the user that they don't have permission to read the pid file.

If you want a middle ground for paranoia, you can use:

%attr(0710,root,apache)

Have 'x' is sufficient for things which know the name of a file in the directory to access it. You only need 'r' if want to allow browsing of the directory. Ie., get a directory listing. The mod_wsgi doesn't need browsing ability and doubt that mod_fcgid would either.

In the thread on mod_wsgi list about this, Clodoaldo Pinto Neto had validated that 0710 is sufficient for mod_wsgi and was actually his suggestion that 0710 could be used.

This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

httpd-2.2.14-1.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/httpd-2.2.14-1.fc12

httpd-2.2.14-1.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/httpd-2.2.14-1.fc11

Thanks for all the feedback.  I've changed the perms as Graham indicates above:

%attr(0710,root,apache)

Please test out the 2.2.14-1 packages when they hit updates-testing and post
feedback at the bodhi link above (and here if you like).  This update should
resolve this issue.

httpd-2.2.14-1.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/httpd-2.2.14-1.fc10

httpd-2.2.14-1.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update httpd'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-12606

httpd-2.2.14-1.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update httpd'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-12747

Updated httpd from the updates-testing repository in F11-64 and F12-64 and fixes this bug.

httpd-2.2.14-1.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

httpd-2.2.14-1.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.