Description of problem: With the policy version 3.12.1-106, /usr/sbin/snapperd has the label: system_u:object_r:bin_t:s0 /usr/sbin/snapperd After an upgrade to 3.12.1-119, it's: system_u:object_r:snapperd_exec_t:s0 /usr/sbin/snapperd At this point, running something like snapper list yields a: Failure (org.freedesktop.DBus.Error.Spawn.ExecFailed). SELinux Alert Browser reports this (and yes this is what we want since snapperd is forked by dbus): SELinux is preventing /usr/lib64/dbus-1/dbus-daemon-launch-helper from execute access on the file /usr/sbin/snapperd. Let me know if you need more info. Cheers, Matt
commit ece7f79c5171243ab329b710fac1d48ef275a5a6 Author: Miroslav Grepl <mgrepl> Date: Mon Jan 27 08:23:37 2014 +0100 snapperd is D-Bus service
Hello Miroslav, Out of curiosity, could you tell me where the git repository for the policy is? I found http://pkgs.fedoraproject.org/cgit/selinux-policy.git/ and https://git.fedorahosted.org/cgit/selinux-policy.git/ but none of these seem to be the right thing? Thanks again for your prompt reply. Cheers.
https://git.fedorahosted.org/cgit/selinux-policy.git/commit/?h=f20-contrib&id=ece7f79c5171243ab329b710fac1d48ef275a5a6 new build is coming today.
Cool, thanks.
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
The new build helps but a lot of things are still messed up. Here are some examples: - SELinux is preventing /usr/sbin/snapperd from write access on the directory /var/log (snapperd wants to write to /var/log/snapper.log) - all snapshosts are now mislabeled (or it appears as such): SELinux is preventing /usr/sbin/snapperd from write access on the directory /.snapshots SELinux is preventing /usr/sbin/snapperd from setattr access on the directory /.snapshots/1 SELinux is preventing /usr/sbin/snapperd from ioctl access on the directory /.snapshots/1 SELinux is preventing /usr/sbin/snapperd from getattr access on the file /.snapshots/1/info.xml.tmp-afrkCd Given the sheer number of errors (a 'grep snapperd /var/log/audit/audit.log | audit2allow' returns 349 lines), what would you need from me to help fixing this?
Could you send me compressed /var/log/audit/audit.log file?
Created attachment 856656 [details] Compressed audit.log
There you go. Not sure if you know what snapperd does but if you don't, not only it creates regular snapshots (hourly, daily, ...) but it also creates pre and post yum snapshots. And everytime a snapshot is created, it computes the differences to show you what go changed and so on. It thus means snapperd must be able to walk a whole snapshot of a filesystem...
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).
Created attachment 857956 [details] Compressed audit.log for continuing issues Selinux is still complaining about things that snapper is trying to do... Unlink on info.xml, remove_name and create on info.xml.tmp-xxxxxx, setattr on #, etc. Attached compressed audit.log
*** Bug 1057460 has been marked as a duplicate of this bug. ***
Yes, I am switching it back to assigned. This is more complex bug where we will need to fix brtfs labeling because we end up with file_t. # btrfs subvolume create /home/.snapshots
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.
Wait, this shouldn't be closed, it's still not working at all..
Seeing as this doesn't look like it is going to be fixed quickly, can we revert to the previous behaviour, which worked, because this current bug makes snapper quite unusable. I'm seeing cron.daily get stuck every day and cron.weekly get stuck every week because snapper can't do what it wants to do, and this appears in the journal: Feb 18 06:01:01 Aeolus.local anacron[1898]: Job `cron.daily' locked by another anacron - skipping Feb 18 06:01:01 Aeolus.local anacron[1898]: Job `cron.weekly' locked by another anacron - skipping I have to do a 'sudo killall snapper' every morning to get the rest of the cron scripts to run. The current behaviour is far from optimal.
Could you test it with http://koji.fedoraproject.org/koji/buildinfo?buildID=500802
That seems to do the trick for me, thanks!
Fixed in selinux-policy-3.12.1-128.fc20
selinux-policy-3.12.1-149.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/selinux-policy-3.12.1-149.fc20
Package selinux-policy-3.12.1-149.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-149.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-4604/selinux-policy-3.12.1-149.fc20 then log in and leave karma (feedback).
selinux-policy-3.12.1-149.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.