Download your favorite Linux distribution at LQ ISO.
Go Back > Blogs > Indymaynard
User Name


Rate this Entry


Posted 11-01-2009 at 04:35 PM by Indymaynard

This is one of those funny subjects that you just can't help but see the irony in. Linux users want to write applications in Microsoft programming languages. I only say Microsoft programming languages because it is well known that any language standard that would otherwise exist is immediately smeared under the desk when Microsoft gets their fingers into it.

Getting back on track, I wanted to mess around with Mono a little bit because...because...hmmmm...because it was there. I found the packages for Fedora in the package manager and installed them. This is never the point of failure, so I still had optimism at this point. Then I made sure that mod_mono was there. I was still expecting the best.

Generally, installing from the package manager provides Fedora users with a "it just works" out of the box configuration. I thought this would be one of those cases, so I restarted Apache to ensure that mod_mono would take effect. Suddenly, the SELinux troubleshooting icon appeared in the lower right-hand corner of the screen with a message that said, "AVC denial." This I translated as, "Iceberg dead ahead, Captain! Sound alarm! All hands brace for impact!"

Okay, it's not generally that bad. I don't mind working around little problems. My big problem developed when I found that there was a serious shortage of people who had written pages that helped me accomplish what I wanted to accomplish. Most people disable SELinux. Being interested in maintaining a tighter watch on my server, I do not disable SELinux. Had I done this, my list of problems would certainly have grown exponentially as the script kiddies from,, and the likes may have successfully brute-forced my poor little vsftpd into submission. Disabling SELinux was not an option.

SELinux Troubleshooter was of no help as it referenced "./var" as the item not having the correct context. Aside from the obvious lack of definition for the "." in the reference, I was not even sure what a context was at the time. It turns out that SELinux gives every directory and file a context that is associated with a list of processes and users that are or are not allowed to do certain things to these directories and files. Fedora developers did not include a policy that allowed 2 things; allow httpd to start mono, and allow mono to create a lock and a unix socket.

I can only type this now because I've been dealing with the issue for nigh on 2 or 3 years. The countless hours that I spent learning these important things have been wrought with much anger and frustration. I decided that today was my day to make it work. Today actually turned into 3 days, but I was not dismayed.

The big leap here was going to be learning to properly create an SELinux policy. This is what worked for me. Some of the methods I used were "borrowed" from ljduchez at

It would help to empty your log, but that's not so important. Bash is a very handy tool. Open your shell and login as root, unless you have sudo access. Type in the following commands:

#service httpd restart
#tail /var/log/audit/audit.log | grep mono | audit2allow -M monoallow

#tail /var/log/audit/audit.log | grep httpd | audit2allow -M httpdallow

#semodule -i monoallow.pp; semodule -i httpdallow.pp

#service httpd restart
Step by step, you restart httpd to have any startup messages show up at the end of audit.log. Then, we have two lines which take the end of the audit.log file, search for mono and httpd in the entries, then create policy files for SELinux. The next line "inserts" the new policies to SELinux while the last line again restarts httpd to test for success.

For me, this only solved a portion of the issue. I was receiving fewer log entries regarding mono, but still receiving entries. The last step was to allow mono access to whatever "./var" was.

My reasoning led me to think that if I just did a search for "var" utilizing "Places->Search for files...", I could wind up with a small list of possibilities. Being only mildly intelligent, I was greeted with 430 or so responses. I hadn't remembered that 3 character searches are silly. Reaffirming some of my intelligence, I knew that this mysterious "./var" would probably be a directory. Reasoning more into this, I questioned aloud, "What sort of thing does mono need with a './var'?" My wife then asked me who I was talking to.

Linux uses lockfiles to restrict file access to a single user or process. These lockfiles are stored in /var. My reasoning led me to imagine that mono needed to create a lockfile to limit access to the output to httpd. But how do we tell SELinux to allow mono to do such a thing? We could change the context of the directory, but that will probably break some other stuff.

This is where the journey of discovery began. Using "SELinux Policy Generation Tool", I solved the last problem. I think it's pretty close to what we needed. Step by step:

Click "Applications->System Tools->SELinux Policy Generation Tool".

Enter your root password.

Click "Forward."

Select "User Application." Click "Forward."

Enter "mod_mono" or something similar for the name, and select, "/usr/bin/mono" as the executable. Click "Forward."

Select "unconfined_u" and click "Forward" 3 times.

Select "Create/Manipulate temporary files in /tmp" and "Sends audit messages." Click "Forward."

Click "Add Directory" and select "var" from the root directory. Click "Forward."

I'm not sure if this next step is needed, but I did it anyway. Click "Add Boolean." I named mine, "mod_mono_allowchange_var", but you can change that. You can enter a description if you would like. Click "Add" and then "Forward."

In "Policy Directory", it defaults to your home folder. I would just leave that there. Click "Forward." Click "Apply."

You will now have some files in your home directory that bear the name you typed in for this policy. Open the shell again, and you should be in your home directory. If you also named your policy, "mod_mono", you will have a file named, "" in your root directory. As root, enter the following:

You will see a bunch of stuff happen, but when it is all done, you should be able to restart httpd and see if you have success.

#service httpd restart
If nothing pops up from SELinux Troubleshooter, you should be ready to configure. Good luck!
Posted in Uncategorized
Views 1600 Comments 0
« Prev     Main     Next »
Total Comments 0




All times are GMT -5. The time now is 12:58 AM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration