Description of problem: I'm seeing the following in /var/log/messages: # grep "avc.*denied" /var/log/messages Nov 6 09:19:41 ip-10-62-83-156 kernel: [399654.738880] type=1400 audit(1383729579.090:4): avc: denied { setattr } for pid=183 comm="systemd-tmpfile" name="journal" dev="xvda1" ino=255451 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=dir Nov 6 09:19:41 ip-10-62-83-156 kernel: [399654.738953] type=1400 audit(1383729579.090:5): avc: denied { setattr } for pid=183 comm="systemd-tmpfile" name="7bd3c66a3d974c51b7a407a5bd3073b9" dev="xvda1" ino=385758 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=dir [root@ip-10-62-83-156 ~]# find /var/log/ -inum 255451 /var/log/journal [root@ip-10-62-83-156 ~]# find /var/log/ -inum 385758 /var/log/journal/7bd3c66a3d974c51b7a407a5bd3073b9 Version-Release number of selected component (if applicable): systemd-208-4.fc20.x86_64 How reproducible: always Steps to Reproduce: I've done my testing for F20-Beta-RC4 AMI on EC2 only, but should be reproducible on bare metal as well 1. Start F20-Beta-RC4 AMI on EC2 2. Do 'yum update' 3. Reboot Actual results: avc: denied messages Expected results: no denials Additional info:
I can also see: Nov 6 09:19:40 ip-10-62-83-156 systemd-tmpfiles: chmod(/var/log/journal) failed: Permission denied Nov 6 09:19:40 ip-10-62-83-156 systemd-tmpfiles: chmod(/var/log/journal/7bd3c66a3d974c51b7a407a5bd3073b9) failed: Permission denied in /var/log/messages
Confirm that. I have to add the following rule: https://github.com/lemenkov/selinux-rules/blob/master/auriga-systemd-tmpfiles.te module auriga-systemd-tmpfiles 1.0; require { type systemd_tmpfiles_t; type var_log_t; class dir { relabelfrom relabelto setattr }; } #============= systemd_tmpfiles_t ============== allow systemd_tmpfiles_t var_log_t:dir { relabelfrom relabelto setattr };
Hm, I get a slightly simpler result from audit2allow: #============= systemd_tmpfiles_t ============== allow systemd_tmpfiles_t var_log_t:dir setattr; Either way, can we get this applied? This results in an annoying warning for probably all F20 installations?
systemd changed in http://cgit.freedesktop.org/systemd/systemd/commit/?id=4608af43.
Seen here: http://beaker.fedoraproject.org/bkr/jobs/51 will re-test with the latest.
Looks like the latest code in F20 allows this. selinux-policy-3.12.1-120.fc20 or earlier.
selinux-policy-3.12.1-121.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/selinux-policy-3.12.1-121.fc20
Package selinux-policy-3.12.1-121.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.12.1-121.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-1700/selinux-policy-3.12.1-121.fc20 then log in and leave karma (feedback).
Package selinux-policy-3.12.1-122.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.12.1-122.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-1700/selinux-policy-3.12.1-122.fc20 then log in and leave karma (feedback).
selinux-policy-3.12.1-122.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.