Puzzling trac permissions error
116 views
Skip to first unread message
Niles Oien
Feb 9, 2018, 3:01:23 PM2/9/18
to Trac Users
Hi all,
I have a puzzling error.
I am running on CentOS Linux release 7.4.1708. I installed trac-1.0.13-1.el7.noarch through yum. I'm trying to get an initial trac setup going. In my httpd.conf I have :
WSGIScriptAlias /trac /var/www/trac/trac.wsgi
<Directory /var/www/trac>
WSGIApplicationGroup %{GLOBAL}
# For Apache 2.2
# <IfModule !mod_authz_core.c>
# Order deny,allow
# Allow from all
# </IfModule>
# For Apache 2.4
<IfModule mod_authz_core.c>
Require all granted
</IfModule>
</Directory>
I did an initenv and deploy with trac-admin.
If I pull up the trac web page, it comes up in a browser, but I get this message :
Error with navigation contributor "BrowserModule"
Can't synchronize with repository "(default)" (The user <tt>apache</tt> requires read _and_ write permissions to the database file /var/www/trac/db/trac.db and the directory it is located in.). Look in the Trac log for more information.
The user apache requires read _and_ write permissions to the database file /var/www/trac/db/trac.db and the directory it is located in.
And if I turn logging on so I can look at the log, I get this in the browser :
TracError: IOError: [Errno 13] Permission denied: u'/var/www/trac/log/trac.log'
So, basically, both errors would sem to be traceable to nothing under /var/www/trac/ being 'apache' read-writeable.
But I've done this :
chown -R apache:apache /var/www/trac
I can su -m apache and create and delete files under /var/www/trac as apache. I can run sqlite3 like so : sqlite3 db/trac.db --- and then I can do updates on tables in the database, and reverse them. I've tried this simple WSGI script to test the apache/mod_wsgi/python setup :
def application(environ, start_response):
start_response('200 OK',[('Content-type','text/html')])
return ['<html><body>Hello World!</body></html>']
And it seems to work (I get "Hello world" in the browser).
I don't see anything in the apache error logs, and nothing unremarkable in the access logs. The apache setup is utterly vanilla, nothing at all non standard, it certainly seems to be running as user apache.
Please help, it's quite baffling - all the error messages I'm getting suggest that it's a permissions issue for user apache under /var/www/trac/ and I am absolutely not seeing that.
Thanks,
Niles Oien National SOlar Observatory Boulder CO
RjOllos
Feb 9, 2018, 5:49:03 PM2/9/18
to Trac Users
That does seem strange. Can you confirm that user apache has r/w permissions for /var/www as well?
You could try running tracd with strace as the apache user. I haven't used strace much so unsure if that will show much that's useful.
- Ryan
Niles Oien
Feb 9, 2018, 11:49:12 PM2/9/18
to Trac Users
I just changed ownership on /var/www to apache:apache - it was root:root. It made no difference.
I set up a URL that shows it not being able to write to the database :
http://netdrms02.nispdc.nso.edu/Niles
And another one with logging enabled that shows it not being able to write the trac log :
http://netdrms02.nispdc.nso.edu/NilesLog
Which, given that I can do both those things when I su -m to apache, is just weird. And without a log, I can't really proceed - I have no idea what's going on. Any help appreciated.
Thanks,
Niles.
Dan Stromberg
Feb 10, 2018, 11:12:26 AM2/10/18
to trac-...@googlegroups.com
Perhaps try:
http://stromberg.dnsalias.org/~strombrg/debugging-with-syscall-tracers.html
?
The error you're looking for will likely be an EPERM.
If you're not comfortable reading syscall traces, you could put them
result on a web server and send us a URL.
http://stromberg.dnsalias.org/~strombrg/debugging-with-syscall-tracers.html
?
The error you're looking for will likely be an EPERM.
If you're not comfortable reading syscall traces, you could put them
result on a web server and send us a URL.
RjOllos
Feb 12, 2018, 12:58:16 PM2/12/18
to Trac Users
On Friday, February 9, 2018 at 11:49:12 PM UTC-5, Niles Oien wrote:
I just changed ownership on /var/www to apache:apache - it was root:root. It made no difference.
I set up a URL that shows it not being able to write to the database :
http://netdrms02.nispdc.nso.edu/Niles
And another one with logging enabled that shows it not being able to write the trac log :
http://netdrms02.nispdc.nso.edu/NilesLog
Which, given that I can do both those things when I su -m to apache, is just weird. And without a log, I can't really proceed - I have no idea what's going on. Any help appreciated.
Thanks,
Niles.
Following the suggested debug steps with strace or as Dan suggested is the best way to go.
You could also run and report to us the following:
$ find /path/to/trac/env -exec ls -l {} \;
I would stop Apache and try running with tracd (Trac Standalone) under user Apache, to see if you get any of the same errors.
- Ryan
Niles Oien
Feb 13, 2018, 3:04:08 PM2/13/18
to Trac Users
It took me a couple of days to get back to this. I looked at it fpor a while today. I'm completely baffled.
In the end I went with a *very* stripped down setup that doesn't even have trac in it, and I still get errors, so I *guess* it's an apache config error?
What I have in httpd.conf is :
WSGIScriptAlias /apacheTest /usr/local/apacheTest/wsgiTest.wsgi
<Directory /usr/local/apacheTest>
Order allow,deny
Allow from all
Require all granted
</Directory>
And in wsgiTest.wsgi :
#!/usr/bin/python
import os
import subprocess
def application(environ, start_response):
start_response('200 OK',[('Content-type','text/html')])
whoami=subprocess.check_output(['/bin/whoami'])
pwd=subprocess.check_output(['/bin/pwd'])
date=subprocess.check_output(['/bin/date'])
envStr=""
for key in os.environ.keys():
envStr = envStr + '<B>' + key + '</b> is set to <B>' + os.environ[key] + '</b><br>\n'
statusStr="File operation <B>OK</b>"
try:
file=open('/usr/local/apacheTest/testTimes.dat', 'a')
file.write(date)
file.close()
except:
statusStr="File operation <B>FAILED</b>"
return ['<html><body>In WSGI test script with env :<br>' + envStr +
'<br><br>/bin/pwd returned : ' + pwd +
'<br>/bin/whoami returned : ' + whoami +
'<br><br>' + statusStr + '<br><br>' +
date + '</body></html>']
And the result is that is shows this :
http://netdrms02.nispdc.nso.edu/apacheTest/
Or, to cut-and-paste that web page into this reply, it shows that the wsgi script is being run by user apache with a minimal path and environment, and that the attempt to write to a file in the apacheTest/ directory (which is owned by apache - I made sure of that!) fails. So that web page looks like this :
In WSGI test script with env :
LANG is set to C
PATH is set to /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
NOTIFY_SOCKET is set to /run/systemd/notify
/bin/pwd returned : /
/bin/whoami returned : apache
File operation FAILED
Tue Feb 13 12:46:55 MST 2018
The thing is, I can "su -m apache" and then cd into that directory and run a python script that is essentially a copy of the wsgiTest.wsgi (but run as main rather than as a function) and it all just works. I don't see anything in the apache error logs, either.
I know everyone said to run tracd under strace, and really, THANK YOU for that suggestion, but I wanted to try this first. It seems like it's something in the Apache setup? Or the configuration of mod_wsgi? And I can't see what, although I'm not very familiar with either of those things.
Any thoughts/suggestions appreciated!
pwd=subprocess.check_output(['/bin/pwd'])
date=subprocess.check_output(['/bin/date'])
envStr=""
for key in os.environ.keys():
envStr = envStr + '<B>' + key + '</b> is set to <B>' + os.environ[key] + '</b><br>\n'
statusStr="File operation <B>OK</b>"
try:
file=open('/usr/local/apacheTest/testTimes.dat', 'a')
file.write(date)
file.close()
except:
statusStr="File operation <B>FAILED</b>"
return ['<html><body>In WSGI test script with env :<br>' + envStr +
'<br><br>/bin/pwd returned : ' + pwd +
'<br>/bin/whoami returned : ' + whoami +
'<br><br>' + statusStr + '<br><br>' +
date + '</body></html>']
And the result is that is shows this :
http://netdrms02.nispdc.nso.edu/apacheTest/
Or, to cut-and-paste that web page into this reply, it shows that the wsgi script is being run by user apache with a minimal path and environment, and that the attempt to write to a file in the apacheTest/ directory (which is owned by apache - I made sure of that!) fails. So that web page looks like this :
In WSGI test script with env :
LANG is set to C
PATH is set to /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
NOTIFY_SOCKET is set to /run/systemd/notify
/bin/pwd returned : /
/bin/whoami returned : apache
File operation FAILED
Tue Feb 13 12:46:55 MST 2018
The thing is, I can "su -m apache" and then cd into that directory and run a python script that is essentially a copy of the wsgiTest.wsgi (but run as main rather than as a function) and it all just works. I don't see anything in the apache error logs, either.
I know everyone said to run tracd under strace, and really, THANK YOU for that suggestion, but I wanted to try this first. It seems like it's something in the Apache setup? Or the configuration of mod_wsgi? And I can't see what, although I'm not very familiar with either of those things.
Any thoughts/suggestions appreciated!
On Friday, February 9, 2018 at 1:01:23 PM UTC-7, Niles Oien wrote:
Dimitri Maziuk
Feb 13, 2018, 3:10:32 PM2/13/18
to trac-...@googlegroups.com
On 02/13/2018 02:04 PM, Niles Oien wrote:
> Or, to cut-and-paste that web page into this reply, it shows that the wsgi
> script is being run by user apache with a minimal path and environment, and
> that the attempt to write to a file in the apacheTest/ directory (which is
> owned by apache - I made sure of that!) fails.
SELinux?
> Or, to cut-and-paste that web page into this reply, it shows that the wsgi
> script is being run by user apache with a minimal path and environment, and
> that the attempt to write to a file in the apacheTest/ directory (which is
> owned by apache - I made sure of that!) fails.
The other one is chattr/lsattr but if haven't changed those, they
shouldn't be there. The other other common ones have to do with mounts
and shouldn't apply if it's a local directory.
--
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu
Niles Oien
Feb 13, 2018, 4:25:18 PM2/13/18
to Trac Users
I'm on CentOS 7. I have not seen chattr/lsattr set, but I'll keep an eye out.
RjOllos
Feb 13, 2018, 8:41:16 PM2/13/18
to Trac Users
On Tuesday, February 13, 2018 at 3:04:08 PM UTC-5, Niles Oien wrote:
It took me a couple of days to get back to this. I looked at it fpor a while today. I'm completely baffled.
In the end I went with a *very* stripped down setup that doesn't even have trac in it, and I still get errors, so I *guess* it's an apache config error?
What I have in httpd.conf is :
WSGIScriptAlias /apacheTest /usr/local/apacheTest/wsgiTest.wsgi
<Directory /usr/local/apacheTest>
Order allow,deny
Allow from all
Require all granted
</Directory>
The mixes pre-Apache-2.4 and Apache-2.4 syntax. Please try:
<Directory /usr/local/apacheTest>
Require all granted
</Directory>
Our example in the documentation is:
<Directory /usr/local/trac/mysite/apache>
WSGIApplicationGroup %{GLOBAL}
# For Apache 2.2
<IfModule !mod_authz_core.c>
Order deny,allow
Allow from all
</IfModule>
# For Apache 2.4
<IfModule mod_authz_core.c>
Require all granted
</IfModule>
</Directory>
That's meant to work on Apache 2.2 and 2.4, by using a test for existence of mod_authz_core.c. It's possible that doesn't work correctly in all cases. If you are using Apache 2.4, you can simplify the example to:
<Directory /usr/local/trac/mysite/apache>
WSGIApplicationGroup %{GLOBAL}
Require all granted
</Directory>
- Ryan
Niles Oien
Feb 15, 2018, 10:25:23 AM2/15/18
to Trac Users
I'm embarrassed - it turned out that the system was running SElinux. Changing that resolved the issue. I had not heard of SElinux before, in fact when I saw it written I thought it referred to SuSE Enterprise linux.
The little WSGI test script I posted was pretty useful, I have to say, it was good to know what user was running the script and what their environment was. So I guess that is a contribution of sorts.
Thanks you all for all your suggestions,
Niles.
On Friday, February 9, 2018 at 1:01:23 PM UTC-7, Niles Oien wrote:
Dimitri Maziuk
Feb 15, 2018, 1:33:54 PM2/15/18
to trac-...@googlegroups.com
On 02/15/2018 09:25 AM, Niles Oien wrote:
>
>
> I'm embarrassed - it turned out that the system was running SElinux.
That's what I said, but it looks like thunderbird's quoting style made
>
>
> I'm embarrassed - it turned out that the system was running SElinux.
that not very obvious. ;)
Reply all
Reply to author
Forward
0 new messages