| Message ID | 20200618182205.378233-1-jlebon@redhat.com (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [v2] setfiles: clarify documented path resolution behaviour | expand |
On Thu, Jun 18, 2020 at 3:05 PM Jonathan Lebon <jlebon@redhat.com> wrote: > > 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>
On Mon, Jun 22, 2020 at 8:25 AM Stephen Smalley <stephen.smalley.work@gmail.com> wrote: > > On Thu, Jun 18, 2020 at 3:05 PM Jonathan Lebon <jlebon@redhat.com> wrote: > > > > 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> Applied.
diff --git a/policycoreutils/setfiles/restorecon.8 b/policycoreutils/setfiles/restorecon.8 index bbfc83fe..1a785258 100644 --- a/policycoreutils/setfiles/restorecon.8 +++ b/policycoreutils/setfiles/restorecon.8 @@ -159,8 +159,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 diff --git a/policycoreutils/setfiles/setfiles.8 b/policycoreutils/setfiles/setfiles.8 index 0188a75a..e328a562 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. Paths leading up the final +component of the file(s) are not canonicalized before labeling. .IP "2." 4 If the .I pathname
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> --- policycoreutils/setfiles/restorecon.8 | 6 ++++-- policycoreutils/setfiles/setfiles.8 | 3 ++- 2 files changed, 6 insertions(+), 3 deletions(-)