SELinux does not like Subversion

I thought I had a trivial(?) task to complete last week – install and configure subversion on a Linux machine. And I thought, aah.. the easiest task this week. All I had to do was yum the packages, copy a few lines of configuration into ssl.conf (of apache) and do a ‘svnadmin create’. If someone really wants users, just add a svn authorization file.

But things were not to be so easy! To begin with the machine was a RH9 with a lot of packages messed up (including rpm, and no yum). Even the browser would not work. So, after spending an hour with the machine and knowing it had no important data, the best thing I thought of was to upgrade the machine to FC3, and that went smooth.

The next steps to get and upgrade the required packages using yum worked like a charm. Using tips from a Blog on the net (read it quite a few months back, and can’t recall or relocate the location) the required update checks include:

• autoconf
• libtool
• python2
• expat
• db4 (The Berkeley DB)
• neon

And of course subversion and mod_dav_subversion. I went ahead and updated httpd and mod_ssl also. For those behind MS ISA proxies requiring NTLM authentication, there is this wonderful tool worth looking at NTLMAPS (http://ntlmaps.sourceforge.net/).

Since we required the repository accessible over SSL only, I got the SSL certificates installed (see my blog on that – SSL Certificates for your HTTPS server) and added the DAV configuration for SVN in the SSL virtual host:

<location /repo/virtual/location>
DAV svn
SVNParentPath /path/to/repo/parent/dir 

# Authorization
AuthzSVNAccessFile /path/to/svn/authorization/file

# Require authentication for all users
Require valid-user

# How to Authenticate
AuthType Basic
AuthName “Subversion Repository”
AuthUserFile /path/to/user/file
</location>

Created the repository, set up the access permissions, created the users in the userfile (using htpasswd). And then Apache just wouldn’t accept the user id and password. A quick look at the error logs told me that it was denied access to the file (Error code 13). Googling around did not help me either. Just to test out stuff, I tried accessing the repository without authentication, no luck there either, access to the repository was denied.

I sent in a mail to the HTTPD users mailing list (archived here) and the reply got some good news to me, the problem was apparently with SELinux features in FC3 which runs the httpd process in a separate context.

The solution from then on involved a bit of reading (Two links I would suggest – http://fedora.redhat.com/docs/selinux-faq-fc3/index.html and http://fedora.redhat.com/docs/selinux-apache-fc3/index.html) and setting up the correct contexts to the data in the permissions files and the repository. I ended up creating a new policy context for the repository – it required write permissions to the httpd process (not by a script), and I hated having to give write permissions to the process on all HTTP content in the system.

Now the repository works great. And, what started off promising to be an easy 2 hour exercise ended up eating up a few days, but has left me a lot wiser. Nonetheless, I still am having problems with Berkeley DB and Subversion on this, so I am running the repository using the fsfs file system. Need to investigate a bit more on that.