RepoMirrors
/
selinux
mirror of https://github.com/SELinuxProject/selinux
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

setfiles: clarify documented path resolution behaviour 

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.

Signed-off-by: Jonathan Lebon <jlebon@redhat.com>
Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>
This commit is contained in:
Jonathan Lebon 2020-06-18 14:22:07 -04:00 committed by Stephen Smalley
parent da3bbc31a8
commit 5f844b6991
2 changed files with 6 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
policycoreutils/setfiles/restorecon.8
View File

@ -166,8 +166,10 @@ 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. Paths leading up the
final component of the file(s) are canonicalized using
.BR realpath (3)
before labeling.
.IP "2." 4
If the
.I pathname

3
policycoreutils/setfiles/setfiles.8
View File

@ -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. Paths leading up the final
component of the file(s) are not canonicalized before labeling.
.IP "2." 4
If the
.I pathname