Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to configure SELinux on a Red Hat Enterprise Linux 6.2 web server that runs Apache 2.2.15 and Perl 5.10.1, and connects to remote Oracle databases. The Oracle 11.2g client is installed. The PHP scripts that access Oracle are working, but the Perl scripts are not. When SELinux is enforcing and I try to access the Perl scripts through my web browser, Apache's error logs show this message:

Can't load '/usr/local/lib64/perl5/auto/DBD/Oracle/' for module DBD::Oracle: cannot open shared object file: No such file or directory at /usr/lib64/perl5/ line 200.

Oddly, the audit log does not record any corresponding messages. However, when I run set SELinux to permissive mode, the Perl script works perfectly.

This is the output of ls -lZ on

-rwxr-xr-x. oracle oracle system_u:object_r:textrel_shlib_t:s0 /path/to/oracle/product/11.2.0/client/lib/

Does anyone have any suggestions to fix this? I would like to be able to run the web server with SELinux.

UPDATE: After setting selinux to dontaudit, I got more output in audit.log. However, the module I created with audit2allow does not install. The output of semodule -i is: semodule: Failed on cgi_oracle!

cgi_oracle.te contains:

module cgi_oracle 1.0;

require {
    type httpd_log_t;
    type httpd_t;
    type httpd_sys_script_t;
    class process { siginh noatsecure rlimitinh };
    class file { read write };

#============= httpd_sys_script_t ==============
allow httpd_sys_script_t httpd_log_t:file { read write };

#============= httpd_t ==============
allow httpd_t httpd_sys_script_t:process { siginh rlimitinh noatsecure };
share|improve this question
up vote 3 down vote accepted

A number of SELinux policies are flagged dontaudit so that they do not leave messages in the audit log. This is usually because they are policies that would just spam the log with useless entries, but sometimes developers dontaudit a denial rather than fixing the underlying problem. The policy you're hitting is almost certainly among these, since you aren't seeing any messages being logged in audit.log.

You can temporarily disable dontaudit by running:

semodule -DB

After you've discovered the cause of the problem, re-enable dontaudit with:

semodule -B

To build your policy once you've generated it, run:

make -f /usr/share/selinux/devel/Makefile
share|improve this answer
semodule -DB did give more output in audit.log, but after I used audit2allow to create a module, semodule could not install it. The output of semodule -i is: semodule: Failed on cgi_oracle! – slec Aug 8 '12 at 1:29
I've posted the contents of cgi_oracle.te (the module I created with audit2allow) in an edit to my original question. – slec Aug 8 '12 at 1:36
allow httpd_t httpd_sys_script_t:process { siginh rlimitinh noatsecure }; is spurious and you shouldn't need to include it. – Michael Hampton Aug 8 '12 at 1:36
I just tried excluding the siginh, rlimitinh, and noatsecure errors and running audit2allow. semodule failed again when trying to install the resulting module. – slec Aug 8 '12 at 1:42
You should be using make -f /usr/share/selinux/devel/Makefile to compile your policy module. – Michael Hampton Aug 8 '12 at 3:57

To correctly identify the problem - you must run test with SELinux permissive mode, otherwise you will need to run tests one by one and might take a time. After, stop web service, be sure that your audit logs are empty or rotated, run web service, run scripts/test, check audit logs and write new policy. As I understand your scripts want to access oracle libraries for read, so you will need to add read permission for "system_u:object_r:textrel_shlib_t:s0" on your application. I don't know what is the labeling structure for oracle, but i'm sure you can find out. Check audit2allow.

share|improve this answer

You can also try setroubleshoot.. it will also give you clues to what is being restricted and the commands to resolve the issue. Most of the time all you have to do is copy and paste exactly what is given.

yum install -y setroubleshoot


grep setrouble /var/log/messages

For example:

Aug  6 12:36:11 cnt3 setroubleshoot: [avc.ERROR] Plugin Exception catchall_boolean #012Traceback (most recent call last):#012  File "/usr/lib/python2.6/site-packages/setroubleshoot/", line 191, in analyze_avc#012    report = plugin.analyze(avc)#012  File "/usr/share/setroubleshoot/plugins/", line 90, in analyze#012    man_page = self.check_for_man(b)#012  File "/usr/share/setroubleshoot/plugins/", line 76, in check_for_man#012    man_page = name.split("_")[0] + "_selinux"#012AttributeError: 'tuple' object has no attribute 'split'
Aug  6 12:36:11 cnt3 setroubleshoot: SELinux is preventing /usr/libexec/gdm-session-worker from read access on the directory /root. For complete SELinux messages. run sealert -l 721b07e3-e0e2-4a0e-a676-8eb622f7ce01

sealert -l 721b07e3-e0e2-4a0e-a676-8eb622f7ce01

sealert -l 721b07e3-e0e2-4a0e-a676-8eb622f7ce01
SELinux is preventing /usr/libexec/gdm-session-worker from read access on the directory /root.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that gdm-session-worker should be allowed read access on the root directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing:

grep gdm-session-wor /var/log/audit/audit.log | audit2allow -M mypol
semodule -i mypol.pp

Follow what the sealert -l tells you, and I think your problem should be solved. Hope that helps.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.