Bug 982715
Summary: | SELinux is preventing /usr/sbin/mdadm from write access on the file /var/log/rear/rear-ws1.log | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Emmett Culley <lst_manage> |
Component: | rear | Assignee: | Gratien D'haese <gratien.dhaese> |
Status: | CLOSED WORKSFORME | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | unspecified | ||
Version: | 19 | CC: | agk, dledford, dominick.grift, dwalsh, gratien.dhaese, i, Jes.Sorensen, mgrepl |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-12-23 11:47:32 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Emmett Culley
2013-07-09 16:20:43 UTC
Do you have some kind of cron job that is outputing to /var/log/rear/rear-ws1.log Can you read /etc/selinux/targeted/policy/policy.29 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. 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 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. I take it back. It is not fixed as I saw this alert again yesterday. 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. Any chance to look on your cron jobs if there is a job handling /var/log/rear/rear-ws1.log? 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 there? Jes 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. 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 Daniel, 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. Cheers, Jes 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 couldn't reproduce the error report - sorry - bug report is just hanging here - we better close it and re-open it if required. |