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