Red Hat Bugzilla – Bug 213478
webalizer: Error: Can't change directory to /var/www/usage
Last modified: 2007-11-30 17:11:47 EST
Description of problem: Webalizer fails with the error: Error: Can't change directory to /var/www/usage An strace shows: chdir("/var/www/usage") = -1 EACCES (Permission denied) The directory and its context appear correct: # ls -ldZ /var/www/usage/ drwxr-xr-x webalizer root system_u:object_r:httpd_sys_content_t /var/www/usage No audits are issued when the failure occurs, however, setting selinux to permissive mode allows webalizer to run successfully. Version-Release number of selected component (if applicable): webalizer-2.01_10-30.1 How reproducible: Always Steps to Reproduce: 1. Run /usr/bin/webalizer 2. Confirm error 3. setenforce 0 4. Run /usr/bin/webalizer 5. Confirm success Actual results: Error: Can't change directory to /var/www/usage Expected results: No error Additional info:
Did you look in /var/log/audit/audit.log for messages?
I didn't have audit installed at the time, so there was no audit.log (see bug #212750). Without it, 'audit2allow -l -a' showed no AVC messages. After audit was installed, the problem became apparent. This bug and #212750 have the same cause; the audit package not being installed by default in FC6.
And the problem is?
I'm OK with it if you are. I can manually install audit on my systems.
I don't understand, why was webalizer failing. Without audit installed the log messages should go in /var/log/messages
That's the point; without audit, the reporting tools (like audit2allow) which were installed didn't work, so there was no indication of the cause of the failure. Webalizer says "permission denied", the audit tools lie and say "no AVC messages", and the files look like the permissions are OK. Personally, I think audit should be installed by default, otherwise there's no sense in having policycoreutils, since they provide misinformation (no audits).
Could you attach /var/log/messages, the avc messages should have been there. Avc messages are reported in /var/log/messages if the audit daemon is not running. audit2allow -a is supposed to look there.
I can't recreate the problem (I even tried a new install on another machine), and the original /var/log/messages has rotated out, so I'm assuming that it was a file context error (user error) that has since been corrected. Closing.