I thought `restorecon -Rv /` was a valid way to attempt a manual relabel. It's not really, because it doesn't manage to skip `/sys/` and emits many warnings. Anyway the other thing that happens, every time you run it, is this: restorecon reset /usr/sbin/ldconfig context system_u:object_r:bin_t:s0->system_u:object_r:ldconfig_exec_t:s0 restorecon reset /usr/sbin/sln context system_u:object_r:ldconfig_exec_t:s0->system_u:object_r:bin_t:s0 i.e. there are conflicting labels applied to the same inode: $ ls -l /usr/sbin/ldconfig -rwxr-xr-x. 2 root root 1092984 Dec 24 01:03 /usr/sbin/ldconfig $ ls -l /usr/sbin/sln -rwxr-xr-x. 2 root root 1092984 Dec 24 01:03 /usr/sbin/sln I remain very ignorant about SELinux, but I do not think this is a good thing. `sln` is owned by glibc-2.24-4.fc25.x86_64, and it passes `rpm --verify`. Apparently it provides an equivalent of `ln -s`, as a statically linked program. (So you can use it to sort out problems with dynamically linked libraries... presumably you also need a statically linked shell). I do not know why a hardlink is used instead of a symbolic link. Version-Release number of selected component (if applicable): selinux-policy-targeted-3.13.1-225.3.fc25.noarch Expected results: After the first invocation of e.g. `restorecon -Rv /usr`, I expected that subsequent invocations would not generate any output. Additional info: This should be a pretty clean system. It's a recent install of Fedora 25 Workstation. $ sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Max kernel policy version: 30
fixfiles actually detects this case: filespec_add: conflicting specifications for /usr/sbin/sln and /usr/sbin/ldconfig, using system_u:object_r:ldconfig_exec_t:s0. *** This bug has been marked as a duplicate of bug 1403012 ***