I see restorecon always relabels something, e.g. after doing dnf upgrade I'll run restorecon and something or other is always reset.
I can't tell if this is a problem or not, but it seems to me the selinux label for a current package should already be correctly set, rather than depending on restorecon to reset them. Or is there more than one valid labeling possible?
For example, the kernel packages are always affected. This is what I got today after installing kernel 4.2.6-301
I'm guessing it's the kernel package that's setting the kernel to system_u:object_r:modules_object_t and then restorecon resets it to system_u:object_r:boot_t:s0. So is this a nitpick difference, or should I file a bug against the kernel package so it sets things correctly from the outset? I don't think we should have to do a restorecon after every dnf upgrade or install to make sure labeling is correct.
Similarly, I get: restorecon reset /sys/fs/cgroup context system_u:object_r:tmpfs_t:s0->system_u:object_r:cgroup_t:s0 restorecon set context /sys/fs/cgroup->system_u:object_r:cgroup_t:s0 failed:'Read-only file system'
So, whatever is responsible for setting selinux labels on /sys/fs (?) seems to set that incorrectly, and restorecon can't fix it because it's an ro filesystem. So is that a bug and if so what should it be filed against?
Thanks,
If you see mislabeling issues as you described above then we can talk about policy bugs in most cases.
We have opened issue for the first one - https://github.com/fedora-selinux/selinux-policy/issues/49
The second one is about symlinks.
ls -lZ /sys/fs/cgroup/cpu lrwxrwxrwx. 1 root root system_u:object_r:tmpfs_t:s0 11 Dec 7 23:20 /sys/fs/cgroup/cpu -> cpu,cpuacct
and if you check a target then you will see correct labels. But we define
/sys/fs/cgroup -d gen_context(system_u:object_r:cgroup_t,s0) /sys/fs/cgroup/.* <<none>>
in the policy which is used for labeling. Could you please open a new bug for it?
Thank you.
Regards, Miroslav
selinux@lists.fedoraproject.org