Ask Your Question

How to debug un-listed selinx permissions problems for httpd?

asked 2015-08-24 17:27:16 -0600

Charlweed gravatar image

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:

drwxrwxr-x.  47 unconfined_u:object_r:var_t:s0   hguser repo_users 4.0K Aug 13 16:00 .
drwxrwxr-x.   3 unconfined_u:object_r:var_t:s0   hguser repo_users 4.0K Aug 24 13:24 AStyle

And the document root /var/mercurial looks like this:

drwxrwxr-x.  2 unconfined_u:object_r:var_t:s0   hguser repo_users 4.0K Oct  2  2014 .
-rw-rw-r--.  1 unconfined_u:object_r:var_t:s0   hguser repo_users  12K Dec 19  2012 dummy.html

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.


edit retag flag offensive close merge delete


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.

Charlweed gravatar imageCharlweed ( 2015-08-24 18:32:10 -0600 )edit

Does running restorecon help

restorecon -r /var/repositories/mercurial/
restorecon -r /var/mercurial/
geforce gravatar imagegeforce ( 2015-08-24 19:59:51 -0600 )edit

I don't want to throw out an 'answer' without positive verification, but I can give some pointers:

  • ausearch should work over ssh, ie ausearch -m avc -ts recent. sealert is more part of the desktop notification applet, as I understand it.

  • httpd can't serve var_t labeled files. The easiest way to resolve this would be to move the files to /var/www/ and restorecon after (mv preserves labels).

  • the default labels in /var/www/ might not be appropriate for mercurial. For the full list of relevant labels and booleans, install selinux-policy-doc for man httpd_selinux

randomuser gravatar imagerandomuser ( 2015-08-25 00:39:07 -0600 )edit

1 Answer

Sort by » oldest newest most voted

answered 2015-09-05 14:11:29 -0600

Charlweed gravatar image

updated 2015-09-05 14:20:39 -0600

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.

#Remember that semanage fcontext uses regular expressions, not bash globbing
set -e
set -u


echo chown hguser:repo_users "$hg_web_dir"/*
sudo chown hguser:repo_users "$hg_web_dir"/*
echo chown -R hguser:repo_users "$hg_repo_dir"
sudo chown -R hguser:repo_users "$hg_repo_dir"

sudo chmod 664 "$hg_web_dir""/"*
sudo chmod 775 "$hg_web_dir""hgwebdir.fcgi"

echo find "$hg_repo_dir" -type f -exec sudo chmod 664 {} \;
find      "$hg_repo_dir" -type f -exec sudo chmod 664 {} \;
echo find "$hg_repo_dir" -type d -exec sudo chmod 775 {} \;
find      "$hg_repo_dir" -type d -exec sudo chmod 775 {} \;

echo semanage fcontext --add --type httpd_sys_content_t     "$hg_web_dir""(/.*)?"
sudo semanage fcontext --add --type httpd_sys_content_t     "$hg_web_dir""(/.*)?"
echo semanage fcontext --add --type httpd_sys_script_exec_t "$hg_web_dir""/hgwebdir.fcgi"
sudo semanage fcontext --add --type httpd_sys_script_exec_t "$hg_web_dir""/hgwebdir.fcgi"
echo semanage fcontext --add --type httpd_sys_rw_content_t  "$hg_repo_dir""(/.*)?"
sudo semanage fcontext --add --type httpd_sys_rw_content_t  "$hg_repo_dir""(/.*)?"

echo restorecon -R "$hg_web_dir"
sudo restorecon -R "$hg_web_dir"
echo restorecon -R "$hg_repo_dir"
sudo restorecon -R "$hg_repo_dir"
edit flag offensive delete link more

Question Tools

1 follower


Asked: 2015-08-24 17:27:16 -0600

Seen: 241 times

Last updated: Sep 05 '15