Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 982715 - SELinux is preventing /usr/sbin/mdadm from write access on the file /var/log/rear/rear-ws1.log
Summary: SELinux is preventing /usr/sbin/mdadm from write access on the file /var/log/...
Alias: None
Product: Fedora
Classification: Fedora
Component: rear
Version: 19
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Gratien D'haese
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2013-07-09 16:20 UTC by Emmett Culley
Modified: 2013-12-23 11:47 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-12-23 11:47:32 UTC
Type: Bug

Attachments (Terms of Use)

Description Emmett Culley 2013-07-09 16:20:43 UTC
Description of problem:
Since upgrading from Fedora 17 to Fedoar 19 (via fedup) I am seeing the following from SETroubleshoot:

SELinux is preventing /usr/sbin/mdadm from write access on the file /var/log/rear/rear-ws1.log.

*****  Plugin restorecon (93.9 confidence) suggests  *************************

If you want to fix the label. 
/var/log/rear/rear-ws1.log default label should be var_log_t.
Then you can run restorecon.
# /sbin/restorecon -v /var/log/rear/rear-ws1.log

*****  Plugin leaks (6.10 confidence) suggests  ******************************

If you want to ignore mdadm trying to write access the rear-ws1.log file, because you believe it should not need this access.
Then you should report this as a bug.  
You can generate a local policy module to dontaudit this access.
# grep /usr/sbin/mdadm /var/log/audit/audit.log | audit2allow -D -M mypol
# semodule -i mypol.pp

*****  Plugin catchall (1.43 confidence) suggests  ***************************

If you believe that mdadm should be allowed write access on the rear-ws1.log file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
allow this access for now by executing:
# grep mdadm /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:mdadm_t:s0-s0:c0.c1023
Target Context                system_u:object_r:cron_log_t:s0
Target Objects                /var/log/rear/rear-ws1.log [ file ]
Source                        mdadm
Source Path                   /usr/sbin/mdadm
Port                          <Unknown>
Host                          ws1.webengineer.com
Source RPM Packages           mdadm-3.2.6-19.fc19.x86_64
Target RPM Packages           
Policy RPM                    selinux-policy-3.12.1-59.fc19.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     ws1.webengineer.com
Platform                      Linux ws1.webengineer.com 3.9.9-301.fc19.x86_64 #1
                              SMP Thu Jul 4 15:10:36 UTC 2013 x86_64 x86_64
Alert Count                   2
First Seen                    2013-07-09 01:30:05 PDT
Last Seen                     2013-07-09 01:30:13 PDT
Local ID                      9bdcf8cc-fd0f-489f-9bd9-a8d5f034eb2b

Raw Audit Messages
type=AVC msg=audit(1373358613.735:287): avc:  denied  { write } for  pid=21684 comm="mdadm" path="/var/log/rear/rear-ws1.log" dev="dm-3" ino=2490373 scontext=system_u:system_r:mdadm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cron_log_t:s0 tclass=file

type=SYSCALL msg=audit(1373358613.735:287): arch=x86_64 syscall=execve success=yes exit=0 a0=1cc6460 a1=1cc8d50 a2=1cb4230 a3=8 items=0 ppid=21683 pid=21684 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=18 tty=(none) comm=mdadm exe=/usr/sbin/mdadm subj=system_u:system_r:mdadm_t:s0-s0:c0.c1023 key=(null)

Hash: mdadm,mdadm_t,cron_log_t,file,write

I believe that whatever package installed the rear package should have set the permissions correctly.  Especially during an upgrade.

Version-Release number of selected component (if applicable):
Fully updated Fedora 19 (as of 7/8/13 8:50 AM

How reproducible:
Every time mdadm tries to write to that log.

Steps to Reproduce:
1.  Anytime this machime runs that selinus alert happens

Actual results:
SELinux alert caused my mdamd writing to log

Expected results:

Additional info:

Comment 1 Daniel Walsh 2013-07-09 20:13:53 UTC
Do you have some kind of cron job that is outputing to /var/log/rear/rear-ws1.log

Comment 2 Daniel Walsh 2013-07-09 20:29:01 UTC
 Can you read /etc/selinux/targeted/policy/policy.29

Comment 3 Emmett Culley 2013-07-09 22:22:58 UTC
I assume mdadm was being run by a cron job.  Before I followed the instruction for enabling var_log_t I saw the the file mentioned had cron_log_t access.  Now it is var_log_t.

The file /etc/selinux/targeted/policy/policy.29 appears to be a binary file.  What app should I use to view it.

Comment 4 Daniel Walsh 2013-07-10 23:16:33 UTC
Emmet ignore commend about policy.29 meant for a different bugzilla.

With the label of var_log_t it would still be blocked, have you seen new AVCs

Comment 5 Emmett Culley 2013-07-11 01:50:13 UTC
No I haven't.  And checking the log I found that it was written to this morning, so it seems to have been resolved by the change to var_log_t.

Comment 6 Emmett Culley 2013-07-12 18:09:07 UTC
I take it back.  It is not fixed as I saw this alert again yesterday.

Comment 7 Emmett Culley 2013-07-13 17:33:12 UTC
And I take that last back.  Turns out someting changed it back to cron_log_t

[emmett@ws1 rear]$ ls -Z
-rw-r--r--. root root system_u:object_r:cron_log_t:s0  rear-ws1.log
-rw-r--r--. root root system_u:object_r:cron_log_t:s0  rear-ws1.log.lockless
-rw-r--r--. root root system_u:object_r:cron_log_t:s0  rear-ws1.log.lockless.old
-rw-r--r--. root root system_u:object_r:cron_log_t:s0  rear-ws1.log.old

And I am still seeing this once each day.

Comment 8 Miroslav Grepl 2013-07-15 05:52:09 UTC
Any chance to look on your cron jobs if there is a job handling /var/log/rear/rear-ws1.log?

Comment 9 Jes Sorensen 2013-07-15 07:55:49 UTC
This is the first I have ever heard of the package named 'rear'. I have no
idea why mdadm on your system would try to write to this file - mdadm should
have no knowledge of it at all.

Could you please verify that your /etc/mdadm.conf doesn't try to point it


Comment 10 Daniel Walsh 2013-07-15 21:41:55 UTC
I don't think this has anything to do with mdadm, I think the rear package is redirecting output of its cron jobs to /var/log/rear/rear-ws1.log? via a write and mdadm is just getting handed this as standard out.

SELinux does not like this so it blocks the write access.
If rear had opened the file for append then it probably would work fine.

Comment 11 Emmett Culley 2013-07-16 03:09:12 UTC
There is nothing in mdadm.conf regarding rear.

I checked the /root/install.log and found that rear was install November 20, which is wierd since I skipped Fedora 18.

This didn't start happening until I upgraded my feddora 17 workstation to fedora 19 via fedup.

I see no reference to rear-ws1.log in any file in /etc

Comment 12 Jes Sorensen 2013-07-16 08:17:56 UTC

I agree - I tried installing rear here on my test system, but I still wasn't
able to reproduce the problem. Admittedly I didn't do much besides installing
the rpm.


Comment 13 Gratien D'haese 2013-07-19 08:22:22 UTC
Did a test on Fedora 19 with rear executing from cron:
$ ls -lZ /var/log/rear/
-rw-r--r--. root root system_u:object_r:cron_log_t:s0  rear-fedora19.log
-rw-r--r--. root root unconfined_u:object_r:var_log_t:s0 rear-fedora19.log.old

and afterwards, ran rear manually again:
$ ls -lZ /var/log/rear/
-rw-r--r--. root root unconfined_u:object_r:var_log_t:s0 rear-fedora19.log
-rw-r--r--. root root system_u:object_r:cron_log_t:s0  rear-fedora19.log.old

I did not get an error whatsoever.
The /var/log/rear directory itself has the settings:
$ ls -ldZ /var/log/rear
drwxr-xr-x. root root unconfined_u:object_r:var_log_t:s0 /var/log/rear

Comment 14 Gratien D'haese 2013-12-23 11:47:32 UTC
couldn't reproduce the error report - sorry - bug report is just hanging here - we better close it and re-open it if required.

Note You need to log in before you can comment on or make changes to this bug.