One thing that confused me when investigating https://github.com/SELinuxProject/selinux/issues/248 (i.e. https://github.com/coreos/fedora-coreos-tracker/issues/512) was that the manual page for `setfiles` seemed to imply that paths were fully resolved. This was consistent with the issues above where `setfiles` was failing because the target of the symbolic link didn't exist. But in fact, the wording around symbolic links in `setfiles`/`restorecon` refers actually to whether the parent directories are canonicalized via `realpath(3)` before labeling. Clarify the man pages to explain this. --- policycoreutils/setfiles/restorecon.8 | 4 ++-- policycoreutils/setfiles/setfiles.8 | 3 ++- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/policycoreutils/setfiles/restorecon.8 b/policycoreutils/setfiles/restorecon.8 index bbfc83fe..06ec5a1d 100644 --- a/policycoreutils/setfiles/restorecon.8 +++ b/policycoreutils/setfiles/restorecon.8 @@ -159,8 +159,8 @@ The pathname for the file(s) to be relabeled. .SH "NOTES" .IP "1." 4 .B restorecon -does not follow symbolic links and by default it does not -operate recursively on directories. +by default does not operate recursively on directories. Parent directories +are fully resolved before labeling. .IP "2." 4 If the .I pathname diff --git a/policycoreutils/setfiles/setfiles.8 b/policycoreutils/setfiles/setfiles.8 index 0188a75a..12f41967 100644 --- a/policycoreutils/setfiles/setfiles.8 +++ b/policycoreutils/setfiles/setfiles.8 @@ -214,7 +214,8 @@ option is used. .SH "NOTES" .IP "1." 4 .B setfiles -follows symbolic links and operates recursively on directories. +operates recursively on directories. Parent directories are not fully +resolved before labeling. .IP "2." 4 If the .I pathname -- 2.26.2
