After a few yum updates, I finally noticed that my mercurial web interface was not working anymore. Every attempt to push resulted in

abort: HTTP Error 500: Permission denied

Errors. First I ran sealert –b, but there were no listed denials. I rechecked the ownership and permissions on all the files in the repository, there was no visible problem. I rechecked the httpd conf and the repository confs, same story. I grepped /var/logs/messages, /var/logs/kernel, and /var/logs/audit/audit.log for the string “httpd” and found nothing with any errors or denials. I triedjournalctl –l _SYSTEMD_UNIT=httpd.servcice and got nothing as well.

I used ls –Z on both the repository directory (/var/repositories/mercurial) , and the web document root containing the cgi script (/var/mercurial).
The Repository /var/repositories/mercurial looks like this:

I don’t know much about security contexts and labels and whatever, but the above looks too plain to be correct. Unfortunately, without some kind of error messages logged somewhere, I do not know where to begin.

Finally, I set selinux to permissive, and of course, that “fixed” the issue. Pushes no longer fail. But it is not acceptable to stay in permissive mode. How can I find what the true problem is, correct that, and return to enforcing mode?

FYI, the mercurial hgweb interface is done in python cgi. I will next try grepping and journalctl for python, and see where that gets me.

Comments

Lit looks like sealert is treating ssh logins differently from "console" logins AGAIN. I walked over to the rack, started a graphical login, and "poof!" sealert shows python denials. I had a similar problem in Fedora 18, but I fixed it somehow. Now I must track down that fix, and redo, then I might be able to repair my hgweb server.

1 answer

The best answer on finding hidden denials was given by randomuser: ausearch --message avc --start today

That lets me find the python denials without trekking to the server and opening a local GUI. That reveals the Local ID of the denials. Then I can use sealert --lookupid $id (for example sealert --lookupid 02edf874-c2ce-46f2-a18f-f8254a43cacf) to display the details of the denial, and some possible fixes. In this case, the best chose was to set the selinux contexts for both the mercurial web directory and the all the repository directories. Here is the belt-and-suspenders bash script I used to correct permissions and security contexts. I hope it helps someone, or at least myself in the future. The echos are there for reassurance, as some commands took more than 20 minutes to run on my server.