+++ This bug was initially created as a clone of Bug #1057898 +++ 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 --- Additional comment from Miroslav Grepl on 2014-01-27 03:39:15 EST --- commit ece7f79c5171243ab329b710fac1d48ef275a5a6 Author: Miroslav Grepl <mgrepl> Date: Mon Jan 27 08:23:37 2014 +0100 snapperd is D-Bus service --- Additional comment from Mathieu Chouquet-Stringer on 2014-01-27 05:02:01 EST --- 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. --- Additional comment from Miroslav Grepl on 2014-01-27 05:05:22 EST --- https://git.fedorahosted.org/cgit/selinux-policy.git/commit/?h=f20-contrib&id=ece7f79c5171243ab329b710fac1d48ef275a5a6 new build is coming today. --- Additional comment from Mathieu Chouquet-Stringer on 2014-01-27 05:08:44 EST --- Cool, thanks. --- Additional comment from Fedora Update System on 2014-01-27 14:17:06 EST --- 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 --- Additional comment from Mathieu Chouquet-Stringer on 2014-01-27 15:07:50 EST --- 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? --- Additional comment from Miroslav Grepl on 2014-01-28 02:32:32 EST --- Could you send me compressed /var/log/audit/audit.log file? --- Additional comment from Mathieu Chouquet-Stringer on 2014-01-28 09:49:43 EST --- --- Additional comment from Mathieu Chouquet-Stringer on 2014-01-28 09:54:52 EST --- 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... --- Additional comment from Fedora Update System on 2014-01-28 22:07:07 EST --- 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). --- Additional comment from Fedora Update System on 2014-01-29 22:33:12 EST --- 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). --- Additional comment from Will Tisdale on 2014-01-31 14:08:57 EST --- 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 --- Additional comment from Will Tisdale on 2014-01-31 14:11:43 EST --- --- Additional comment from Miroslav Grepl on 2014-02-03 02:56:41 EST --- 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 --- Additional comment from Fedora Update System on 2014-02-12 09:45:59 EST --- 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. --- Additional comment from Mathieu Chouquet-Stringer on 2014-02-13 17:35:11 EST --- Wait, this shouldn't be closed, it's still not working at all..
I'm still confused as to what people are expecting on this bug. In IRC it was mentioned that btrfs isn't copying the xattrs from the parent dirs to the snapshot. However, that doesn't seem to be the case at all and I see this: [root@localhost /]# btrfs subvolume snapshot / /.snapshot Create a snapshot of '/' in '//.snapshot' [root@localhost /]# ls -lZ /usr/bin/ssh -rwxr-xr-x. root root system_u:object_r:ssh_exec_t:s0 /usr/bin/ssh [root@localhost /]# ls -lZ /.snapshot/usr/bin/ssh -rwxr-xr-x. root root system_u:object_r:ssh_exec_t:s0 /.snapshot/usr/bin/ssh [root@localhost /]# uname -a Linux localhost.localdomain 3.13.3-201.fc20.x86_64 #1 SMP Fri Feb 14 19:08:32 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux [root@localhost /]# rpm -q selinux-policy selinux-policy-3.12.1-122.fc20.noarch [root@localhost /]# So it seems a snapshot of / in /.snapshot has preserved the xattrs as one would expect. If I run just a plain subvolume create, I see: [root@localhost /]# btrfs subvolume create /home/.snapshots Create subvolume '/home/.snapshots' [root@localhost /]# ls -lZ | grep home drwxr-xr-x. root root system_u:object_r:home_root_t:s0 home [root@localhost /]# cd /home/.snapshots/ [root@localhost .snapshots]# touch foo bar [root@localhost .snapshots]# ls -lZ -rw-r--r--. root root unconfined_u:object_r:file_t:s0 bar -rw-r--r--. root root unconfined_u:object_r:file_t:s0 foo [root@localhost .snapshots]# So with a plain subvolume create, there are no SELinux attrs (or rather, they get the default labels). However, I would actually expect that to be the case as a plain subvolume creation is essentially akin to creating a new btrfs filesystem, just in a subdirectory. Btrfs treats it like it's a different device entirely and it can be mounted independently. What exactly is the issue here then? I would expect snapperd to be doing actual snapshot calls, not plain subvolume creation.
Adding Josef and the btrfs folks on CC.
(In reply to Josh Boyer from comment #1) > I'm still confused as to what people are expecting on this bug. In IRC it > was mentioned that btrfs isn't copying the xattrs from the parent dirs to > the snapshot. However, that doesn't seem to be the case at all and I see > this: > > [root@localhost /]# btrfs subvolume snapshot / /.snapshot > Create a snapshot of '/' in '//.snapshot' > [root@localhost /]# ls -lZ /usr/bin/ssh > -rwxr-xr-x. root root system_u:object_r:ssh_exec_t:s0 /usr/bin/ssh > [root@localhost /]# ls -lZ /.snapshot/usr/bin/ssh > -rwxr-xr-x. root root system_u:object_r:ssh_exec_t:s0 /.snapshot/usr/bin/ssh > [root@localhost /]# uname -a > Linux localhost.localdomain 3.13.3-201.fc20.x86_64 #1 SMP Fri Feb 14 > 19:08:32 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > [root@localhost /]# rpm -q selinux-policy > selinux-policy-3.12.1-122.fc20.noarch > [root@localhost /]# > > So it seems a snapshot of / in /.snapshot has preserved the xattrs as one > would expect. If I run just a plain subvolume create, I see: > > [root@localhost /]# btrfs subvolume create /home/.snapshots > Create subvolume '/home/.snapshots' > [root@localhost /]# ls -lZ | grep home > drwxr-xr-x. root root system_u:object_r:home_root_t:s0 home $ ls -alZ /home > [root@localhost /]# cd /home/.snapshots/ > [root@localhost .snapshots]# touch foo bar > [root@localhost .snapshots]# ls -lZ > -rw-r--r--. root root unconfined_u:object_r:file_t:s0 bar > -rw-r--r--. root root unconfined_u:object_r:file_t:s0 foo > [root@localhost .snapshots]# > > So with a plain subvolume create, there are no SELinux attrs (or rather, > they get the default labels). However, I would actually expect that to be > the case as a plain subvolume creation is essentially akin to creating a new > btrfs filesystem, just in a subdirectory. Btrfs treats it like it's a > different device entirely and it can be mounted independently. > > What exactly is the issue here then? I would expect snapperd to be doing > actual snapshot calls, not plain subvolume creation.
(In reply to Josh Boyer from comment #1) > [root@localhost /]# btrfs subvolume create /home/.snapshots > Create subvolume '/home/.snapshots' > [root@localhost /]# ls -lZ | grep home > drwxr-xr-x. root root system_u:object_r:home_root_t:s0 home > [root@localhost /]# cd /home/.snapshots/ > [root@localhost .snapshots]# touch foo bar > [root@localhost .snapshots]# ls -lZ > -rw-r--r--. root root unconfined_u:object_r:file_t:s0 bar > -rw-r--r--. root root unconfined_u:object_r:file_t:s0 foo > [root@localhost .snapshots]# > > So with a plain subvolume create, there are no SELinux attrs (or rather, > they get the default labels). You actually get NO label. That's the fallback label we use when there is nothing at all to use. > However, I would actually expect that to be > the case as a plain subvolume creation is essentially akin to creating a new > btrfs filesystem, just in a subdirectory. Btrfs treats it like it's a > different device entirely and it can be mounted independently. Maybe since btrfs subvolume is doing the 'mounting' as well, we could ask them to just call restorecon on the new mount point? So we get A label on the root inode (and will thus get some sort of reasonable labels on the file created underneath)
(In reply to Miroslav Grepl from comment #3) > (In reply to Josh Boyer from comment #1) > > I'm still confused as to what people are expecting on this bug. In IRC it > > was mentioned that btrfs isn't copying the xattrs from the parent dirs to > > the snapshot. However, that doesn't seem to be the case at all and I see > > this: > > > > [root@localhost /]# btrfs subvolume snapshot / /.snapshot > > Create a snapshot of '/' in '//.snapshot' > > [root@localhost /]# ls -lZ /usr/bin/ssh > > -rwxr-xr-x. root root system_u:object_r:ssh_exec_t:s0 /usr/bin/ssh > > [root@localhost /]# ls -lZ /.snapshot/usr/bin/ssh > > -rwxr-xr-x. root root system_u:object_r:ssh_exec_t:s0 /.snapshot/usr/bin/ssh > > [root@localhost /]# uname -a > > Linux localhost.localdomain 3.13.3-201.fc20.x86_64 #1 SMP Fri Feb 14 > > 19:08:32 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > > [root@localhost /]# rpm -q selinux-policy > > selinux-policy-3.12.1-122.fc20.noarch > > [root@localhost /]# > > > > So it seems a snapshot of / in /.snapshot has preserved the xattrs as one > > would expect. If I run just a plain subvolume create, I see: > > > > [root@localhost /]# btrfs subvolume create /home/.snapshots > > Create subvolume '/home/.snapshots' > > [root@localhost /]# ls -lZ | grep home > > drwxr-xr-x. root root system_u:object_r:home_root_t:s0 home > > $ ls -alZ /home Right. The .snapshots entry doesn't have the same labels as the rest of the things under /home. For completeness: [root@localhost ~]# ls -alZ /home/ drwxr-xr-x. root root system_u:object_r:home_root_t:s0 . drwxr-xr-x. root root system_u:object_r:root_t:s0 .. drwx------. jwboyer jwboyer unconfined_u:object_r:user_home_dir_t:s0 jwboyer drwxr-xr-x. root root system_u:object_r:file_t:s0 .snapshots [root@localhost ~]# However, I'm still not sure if it would actually be expected to. It's not a directory under /home. It just happens to _look_ like a directory. You can't even do a hardlink from /home to /home/.snapshot because it's really a separate device. Inheriting the xattrs from the parent inode on a new subvolume creation might be something that could be done, but I'm not in a position to say whether or not that makes sense. Hopefully Josef can chime in on that one. Also, as I said earlier, shouldn't snapperd actually be using the snapshot functionality, which does preserve the xattrs? I'm confused if we're trying to fix SELinux + snapperd here, or if we've moved onto some more general SELinux + btrfs subvolumes problme space.
(In reply to Eric Paris from comment #4) > (In reply to Josh Boyer from comment #1) > > > [root@localhost /]# btrfs subvolume create /home/.snapshots > > Create subvolume '/home/.snapshots' > > [root@localhost /]# ls -lZ | grep home > > drwxr-xr-x. root root system_u:object_r:home_root_t:s0 home > > [root@localhost /]# cd /home/.snapshots/ > > [root@localhost .snapshots]# touch foo bar > > [root@localhost .snapshots]# ls -lZ > > -rw-r--r--. root root unconfined_u:object_r:file_t:s0 bar > > -rw-r--r--. root root unconfined_u:object_r:file_t:s0 foo > > [root@localhost .snapshots]# > > > > So with a plain subvolume create, there are no SELinux attrs (or rather, > > they get the default labels). > > You actually get NO label. That's the fallback label we use when there is > nothing at all to use. Right, sorry. That's what I meant. > > However, I would actually expect that to be > > the case as a plain subvolume creation is essentially akin to creating a new > > btrfs filesystem, just in a subdirectory. Btrfs treats it like it's a > > different device entirely and it can be mounted independently. > > Maybe since btrfs subvolume is doing the 'mounting' as well, we could ask > them to just call restorecon on the new mount point? So we get A label on > the root inode (and will thus get some sort of reasonable labels on the file > created underneath) Possibly?
Ok, so, snapshots seems to work just fine. 'subvolume create' on the other hand suffers from the same 'problem' as mkfs.ext4. The root inode inside the newly created filesystem has NO label at all. we expect that admins would mount such a new ext4 fs and then use a tool like restorecon to get a label on the root inode of that new FS. btrfs is doing both the mkfs and the mount in one operation. I'd like to ask the btrfs team to add a call to 'restorecon' for the root inode immediately after it is created. should take care of this problem.
btrfs-progs-3.14.1 has been pushed to Fedora 19 and 20 for testing. I frankly have no idea if this will resolve your bug or not, but if you test it and find that it does, please take the opportunity to close this bug. :) Thanks, -Eric
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.