On 8 February 2010 10:31, PatrickB <[email protected]> wrote: > Alright, stopped Apache, the WSGI sockets where automatically removed. > Changed permissions back to normal (chown root.root /var/run/httpd).
Did you do (4), start Apache, before doing (5)? There are no WSGI socket files in there. > 5: > r...@patrick:/var/run# ls -las /var/run > total 96 > 4 drwxr-xr-x 14 root root 4096 2010-02-07 13:01 . > 4 drwxr-xr-x 16 root root 4096 2009-12-23 20:50 .. > 4 -rw-r--r-- 1 root root 5 2010-02-07 00:34 atd.pid > 4 drwxr-xr-x 3 root root 4096 2009-04-26 22:19 cups > 4 drwxr-xr-x 2 root root 4096 2010-02-07 00:34 dbus > 4 drwxr-xr-x 3 root root 4096 2010-02-07 00:34 dovecot > 4 drwxr-xr-x 4 haldaemon haldaemon 4096 2008-12-08 02:14 hald > 4 -rw-r--r-- 1 root root 5 2010-02-07 00:34 hald.pid > 4 drwxrwsrwx 2 root root 4096 2010-02-08 00:27 httpd > 4 -rw-r--r-- 1 root root 5 2010-02-07 00:34 inetd.pid > 4 drwxr-xr-x 2 root root 4096 2009-03-31 14:23 iptraf > 4 -rw-r--r-- 1 root root 5 2010-02-07 00:34 klogd.pid > 4 drwxr-xr-x 2 mysql mysql 4096 2010-02-07 00:34 mysql > 4 drwxr-xr-x 2 root root 4096 2010-02-07 01:55 named > 4 drwxr-xr-x 2 root root 4096 2008-11-21 08:09 nscd > 4 -rw-r--r-- 1 root root 4 2010-02-07 00:34 ntpd.pid > 4 drwxr-xr-x 2 root root 4096 2008-11-15 00:45 proftpd > 4 -rw------- 1 root smmsp 59 2010-02-07 00:34 sendmail.pid > 4 -rw-r--r-- 1 root root 5 2010-02-07 00:34 sshd.pid > 4 drwxr-xr-x 2 root root 4096 2006-09-12 09:33 stunnel > 4 drwx------ 5 root root 4096 2009-12-20 21:46 sudo > 4 -rw-r--r-- 1 root root 5 2010-02-07 00:34 syslogd.pid > 8 -rw-rw-r-- 1 root utmp 4992 2010-02-08 00:26 utmp > > 6: User: apache > Group: apache > > 7: > r...@patrick:/var/run# ps auxwwww | grep httpd > root 27082 0.1 2.7 67920 14400 ? Ss 00:27 0:00 /usr/ > sbin/httpd -k start > patrick 27083 0.0 1.7 125184 9140 ? Sl 00:27 0:00 /usr/ > sbin/httpd -k start > patrick 27091 0.0 1.7 125184 9140 ? Sl 00:27 0:00 /usr/ > sbin/httpd -k start > svn 27099 0.0 1.7 125184 9140 ? Sl 00:27 0:00 /usr/ > sbin/httpd -k start > nqdphp 27107 0.0 1.7 125184 9140 ? Sl 00:27 0:00 /usr/ > sbin/httpd -k start > apache 27115 0.0 1.7 67920 9200 ? S 00:27 0:00 /usr/ > sbin/httpd -k start > apache 27116 0.0 1.7 67920 9200 ? S 00:27 0:00 /usr/ > sbin/httpd -k start > apache 27117 0.0 1.7 67920 9200 ? S 00:27 0:00 /usr/ > sbin/httpd -k start > apache 27118 0.0 1.7 67920 9200 ? S 00:27 0:00 /usr/ > sbin/httpd -k start > apache 27119 0.0 1.7 67920 9200 ? S 00:27 0:00 /usr/ > sbin/httpd -k start > > What I just remembered, I did install mod_ruid to run the httpd > processes as individual users. Could this be what is going wrong here? Yep. That would cause it as the Apache server child processes acting as proxy to WSGI daemon mode processes, if then not running as Apache user, would not be able to access the WSGI listener socket files. > And if so, what can I do to fix this so I can use mod_ruid and > mod_wsgi? Depends on how much you value security and what other Apache modules you are running. You could change the mod_wsgi source code as loosen up the security permissions slightly and it could possibly be made to work. The code change for changing umask on socket creation is easy enough, but you don't want to make it writable by others and would instead at least want to restrict to a group. To do that though you would also need to add new code to mod_wsgi which sets the group ownership of the socket files as at the moment it is left as whatever root uses when Apache is started. I'd have to have a think about whether this is increasing risks of someone breaching Apache/mod_wsgi defences and executing arbitrary code as user that daemon process runs as. What are you do in Apache server child processes that requires mod_ruid. Is it just for file access control or are you allow user in process code to run, such as mod_php, mod_perl or mod_python? Graham > Thanks in advance, > PatrickB > > On 7 feb, 23:29, Graham Dumpleton <[email protected]> wrote: >> You should not be doing a chown or a chmod. Neither should be necessary. >> >> If Apache is being started as root and the Apache user is called >> 'apache', then the WSGI socket files should have ownership as follows: >> >> User: apache >> Group: wheel or daemon or whatever you OS uses for daemon processes >> >> The permissions of the WSGI socket files should from memory be 0600. Ie., >> >> rw------- >> >> The problems with access to socket is usually because the directory >> permissions are wrong, not the socket files themselves. >> >> The directory must be accessible to the Apache user. >> >> On RedHat derived systems, the permissions are locked down so that the >> DEFAULT_REL_RUNTIMEDIR for Apache is not accessible to the Apache >> user. It is not appropriate to be giving that directory less >> restrictive permissions. >> >> The solution on RedHat derived systems is that you use: >> >> WSGISocketPrefix run/wsgi >> >> The 'run' symlink under Apache root should refer to a directory which >> is accessible by Apache user. This directory would normally be: >> >> /var/run >> >> Recently RedHat have been changing the location of the run directory >> so that it is actually: >> >> /var/run/httpd >> >> The 'run' symlink still references it though. >> >> Initially though, whoever decided to do that was creating the >> directory permissions in a way which like the original >> DEFAULT_REL_RUNTIMEDIR was too restrictive and various Apache modules >> where code running as Apache user couldn't access lock files and other >> run time stuff in that directory. Ie., they had: >> >> drwx------ 2 root root 0 Mar 17 15:16 /var/run/httpd >> >> See: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=495780 >> >> To fix the issue properly, they amended the packaged permissions for >> the directory as: >> >> 0710,root,apache >> >> drwx--x--- 2 root apache 0 Mar 17 15:16 /var/run/httpd >> >> Now that I have said all that to provide some context for all the >> issues around this. Do the following: >> >> 1. Shutdown Apache. >> >> 2. Go to /var/run and as root remove any old WSGI lock files. >> >> rm wsgi.*.sock >> >> 3. Ensure that the original permissions and ownership of the /var/run >> directory are restored to their system defaults. >> >> 4. Start Apache. >> >> 5. Send me a long directory list of the /var/run directory. >> >> ls -las /var/run >> >> 6. Send me what settings you have for User/Group directives in Apache. >> >> 7. Send me a 'ps' listing show the Apache processes. >> >> ps auxwwww | grep httpd >> >> or: >> >> ps auxwwww | grep apache >> >> Basically I want to see what the ownership permissions are before you >> started fiddling with anything. >> >> There is no point just telling me what you changed things to as then >> can't work out what original issue may be. >> >> Graham >> >> On 8 February 2010 00:31, PatrickB <[email protected]> wrote: >> >> >> >> > I did both, but it just refuses to work :( >> >> > On Feb 7, 2:06 pm, Clodoaldo Neto <[email protected]> wrote: >> >> 2010/2/7 PatrickB <[email protected]> >> >> >> > I guess the chmoding worked because the default permission there is >> >> > 700 on the sockets. And because the owner is apache.apache, while my >> >> > WSGI processes run as user/group patrick.patrick, trac.trac or another >> >> > user/group. >> >> >> > WSGISocketPrefix is not set, so all the sockets end up in /var/run/ >> >> > httpd. >> >> > If I do "chown root.apache /var/run/httpd" then I get 503 errors >> >> > again :( >> >> > This also happens when I chmod it to 2750. >> >> >> Just to be sure you did it right: The chown and chmod should be both done >> >> not one or the other. >> >> >> Clodoaldo >> >> >> > I also tried "chmod 2775 /var/run/httpd", but that doesn't work >> >> > either. The sockets still have the permission 700... >> >> >> > Regards, PatrickB >> >> >> > On Feb 7, 1:42 pm, Clodoaldo Neto <[email protected]> wrote: >> >> > > 2010/2/7 PatrickB <[email protected]> >> >> >> > > > Hello, >> >> >> > > > I'm using mod_wsgi to host a few Django sites, a few Trac sites and >> >> > > > some Mercurial repositories. I recently moved from one big mod_wsgi >> >> > > > interpreter to a few interpreters by using WSGIDaemonProcess. This >> >> > > > was >> >> > > > working semi-fine, since I forgot to assign directories to the >> >> > > > daemon >> >> > > > processes. I did that now, and I got a load of error messages in all >> >> > > > the logs. The error messages where something like this: >> >> >> > > > [Sun Feb 07 13:00:55 2010] [error] [client 65.55.106.162] >> >> > > > (13)Permission denied: mod_wsgi (pid=19109): Unable to connect to >> >> > > > WSGI >> >> > > > daemon process 'patrickbregman.eu' on '/var/run/wsgi.19074.0.2.sock' >> >> > > > after multiple attempts. >> >> >> > > > I "fixed" this by doing a "chmod 777 /var/run/httpd/wsgi.* ", which >> >> > > > seems to work. For now. Is there a better solution known, or should >> >> > > > I >> >> > > > just modify my Apache initscript to do this for me every time? Not a >> >> > > > big problem for me, but it isn't a very nice solution in my >> >> > > > opninion. >> >> >> > > If mod_wsgi was trying to connect to /var/run/wsgi.#.sock then how >> >> > chmoding >> >> > > /var/run/httpd/wsgi.* worked? >> >> >> > > What is the value of the WSGISocketPrefix directive? >> >> >> > > You can try to chown root.apache the /var/run/httpd directory and then >> >> > chmod >> >> > > it to 2750. >> >> >> > > Regards, Clodoaldo >> >> >> > > > Thanks in advance, >> >> > > > PatrickB >> >> >> > > > -- >> >> > > > 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]<modwsgi%[email protected] >> >> > > > >> >> > <modwsgi%[email protected]<modwsgi%252bunsubscr...@googlegroup >> >> > s.com>> >> >> > > .> For more options, visit this group at >> >> >> > >http://groups.google.com/group/modwsgi?hl=en. >> >> >> > -- >> >> > 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]<modwsgi%[email protected] >> >> > > >> >> > . >> >> > For more options, visit this group at >> >> >http://groups.google.com/group/modwsgi?hl=en. >> >> > -- >> > 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 >> > athttp://groups.google.com/group/modwsgi?hl=en. > > -- > 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. > > -- 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.
