Red Hat Bugzilla – Bug 799131
SELinux prevents embedded Oracle operations on RHEL6.2
Last modified: 2012-09-28 09:49:17 EDT
Description of problem:
I tried to upgrade from RHEL4.4/x86/Satellite5.2.1 to RHEL6.2/x86_64/Satellite5.4.1. While following the upgrade procedure I was unable to complete the schema upgrade due to SELinux.
Entries appeared in my logs similar to the following:
Mar 1 14:58:11 sat setroubleshoot: SELinux is preventing sqlplus from search access on the directory /var/log/audit. For complete SELinux messages. run sealert -l edb75d6b-faa7-4cdb-8eab-0c4e275928c1
Mar 1 14:58:11 sat setroubleshoot: SELinux is preventing oracle from read access on the file ora_2526.aud. For complete SELinux messages. run sealert -l e340a5f6-3d51-487b-921d-5a7f4f16b27d
This manifested in the oracle logs thusly:
Starting Oracle DB instance "rhnsat" ...
SQL*Plus: Release 10.2.0.4.0 - Production on Thu Mar 1 14:44:50 2012
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
SQL> Connected to an idle instance.
SQL> ORA-09925: Unable to create audit trail file
Linux-x86_64 Error: 13: Permission denied
Additional information: 9925
Temporarily disabling SELinux allowed the database upgrade to complete. For a more permanent fix, I created an SELinux module with audit2allow.
Version-Release number of selected component (if applicable):
I was able to make this happen every time when trying to perform the DB migration/upgrade
Steps to Reproduce:
1. Back up database on old Satellite system
2. Restore database on new RHEL6.2-based Satellite system
3. Follow the DB upgrade instructions
Permissions failure due to SELinux
Please contact Red Hat support to help you with the Satellite upgrade issues
you are experiencing and whether or not those issues are valid bug(s) in
RHN Satellite product.
Has this issue been escalated to Red Hat support and / or resolved successfully?
I did not escalate this to support. We created a module w/ audit2allow and moved on.
The problem manifested every time I set up a new instance of RHEL6.2 and tried to install Satellite, so it should not be difficult to reproduce.
All right, what did the denials (those showing during spacewalk-schema-upgrade)
look like exactly?
I'll see if I can reproduce it again.
Alternatively, you can paste the source of the new SELinux modules here.
module RHNSatellite 1.0;
class file read;
#============= oracle_db_t ==============
allow oracle_db_t oracle_common_log_t:file read;
On the Satellite 5.2.1 installation -- has auditing been enabled in the
embedded Oracle database?
I have no idea - we don't have the 5.2.1 installation anymore to check against, either.
As far as 5.4.1 goes, everything is default as far as I know. We really just tried to follow the upgrade instructions included w/ Satellite, to the letter.
You can find out for example by running the following command as root:
# rhn-db-stats - |grep audit
(In reply to comment #10)
> You can find out for example by running the following command as root:
> # rhn-db-stats - |grep audit
Forgot to mention -- this should be run on the 5.4 Satellite.
audit_file_dest string /rhnsat/admin/rhnsat/logs
audit_sys_operations boolean FALSE
audit_trail string NONE
We were able to reproduce the problem described in the initial comment
during upgrades; the fix (updated SELinux policy) will be available
in Satellite 5.5.
Thank you for your report & sorry for the trouble.
Fixed in spacewalk.git master: 025063c2dbef237ed89166f64735da1897856419