I noticed that the rule/usr/sbin/shutdown  --  gen_context(system_u:object_r:shutdown_exec_t,s0)labels /usr/sbin/shutdown shutdown_exec_t when /usr/sbin is a directory. But it doesn't restore the same label when /usr/sbin is a symbolic link to bin and shutdown is in /usr/bin. Why? If /usr/sbin is a symbolic link to bin, is there an easy way to give the files that are supposed to be in /usr/sbin the correct contexts?It looks like that if an inode has 2 hard links to it, and the paths have different default file contexts, the resulting file context will differ depending on which path is given to restorecon. What context will it have if I relabel the whole filesystem? Is it deterministic? Is it ok or good to do so?
How does restorecon handle links?
symlink;selinux;hard link
restorecon doesn't handle symbolic links just the way it handles files.  According to the manual page (a little old, so useful as a starting point):Note  restorecon does not follow symbolic links. This was observed in a bug report, Bug 825221: restorecon disregards custom rules for sym links, with these pertinent comments: Daniel Walsh 2012-05-29 13:54:13 EDT We just fixed this in F17. Daniel Walsh 2012-08-15 14:01:52 EDT restorecon is doing a realpath on the file, so it is translating the file via realpath.  We are doing this so that a symbolic link attack will not cause the file to get mislabeled. Karel Srot 2012-08-23 06:14:05 EDT Just tested this on RHEL6.3 and Fedora 17.On RHEL6 restorecon doesn't restore the context of the symlink (when symlink is the actual item). On Fedora 17 the context is restored. I belive this is the problem mentioned in #c6.Dan, could you please confirm that this is what's is going to be fixed? Thank you. Miroslav Grepl 2012-08-23 09:59:41 EDT Ok, we discovered bug in the policy. We do not have the following rule on RHEL6allow setfiles_t file_type : lnk_file { read getattr relabelfrom relabelto } ;We have justallow setfiles_t file_type : lnk_file { getattr relabelfrom relabelto } ;So I am switching this bug to selinux-policy component.Somewhat later (2015), in Some questions about using restorecon on symlink , Stephen Smalley commentedYes, they resolve to different inodes (a symbolic link is its own  file/inode in Linux, separate and independent of the target). The  symbolic link SELinux label only controls access to the symlink (i.e.  the ability to unlink, rename, or read it), not access to its target  (which is controlled based on the target's label).So... barring some further rule, the symbolic links are (mostly) irrelevant to the permissions on the target that you're concerned about.