[refpolicy] restorecon needs to read bin_t symlinks

[guido@trentalancia.com (Guido Trentalancia)]

On Sat, 19/03/2011 at 21.05 +0100, Sven Vermeulen wrote:
> On Sat, Mar 19, 2011 at 08:54:46PM +0100, Guido Trentalancia wrote:
> > Actually it has nothing to do with restorecon being a symbolic link to
> > the setfiles binary.
> > 
> > Without the "read" capability restorecon is not able to relabel the
> > target file. This is quite bad as we could have non-standard things such
> > as:
> > 
> > ls -al /bin/example_executable
> > lrwxrwxrwx. root root /bin/example_executable
> > -> /opt/example/example_application
> > 
> > and example_application never getting relabelled as bin_t (but instead
> > falling back to usr_t).
> 
> Actually, I would imagine we don't want restorecon to follow symlinks to
> relabel the target files. If we did, then in your example both usr_t and
> bin_t for /opt/example/example_application are valid labels (which isn't
> possible).
> 
> restorecon /bin/example_executable
> restorecon /opt/example/example_application
> 
> The statements would switch the label. A full filesystem relabel, which is
> sometimes touted to be a good solution in case of problems, is in this case
> undecisive as we don't know in which order the files are scanned.

With "lnk_file:read" it just relabels the target file according to the
(unique system-wide) file context definitions. So there won't be
indecision.

My example was wrong (that would never happen). Do we want
setfiles/restorecon to follow symbolic links and relabel the target ?

Regards,

Guido