Permission problem with the sockets in Slackware
PatrickB
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.
Thanks in advance,
PatrickB
Clodoaldo Neto
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 mod...@googlegroups.com.
> To unsubscribe from this group, send email to modwsgi+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
>
PatrickB
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.
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 <clodoaldo.pi...@gmail.com> wrote:
> 2010/2/7 PatrickB <patrick.breg...@gmail.com>
> modwsgi+u...@googlegroups.com<modwsgi%2Bunsu...@googlegroups.com >
> .> For more options, visit this group at
>
> http://groups.google.com/group/modwsgi?hl=en.
>
>
>
>
Clodoaldo Neto
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
To unsubscribe from this group, send email to modwsgi+u...@googlegroups.com.
PatrickB
> > <modwsgi%2Bunsu...@googlegroups.com<modwsgi%252Bunsubscribe@googlegroup s.com>>
Graham Dumpleton
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
> To unsubscribe from this group, send email to modwsgi+u...@googlegroups.com.
PatrickB
Changed permissions back to normal (chown root.root /var/run/httpd).
5:
root@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:
root@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?
And if so, what can I do to fix this so I can use mod_ruid and
mod_wsgi?
Thanks in advance,
PatrickB
Graham Dumpleton
> 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.
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