Bug 1010444 - restorecon -n is not documented well: It does not report mis-labeled files unless -v is specified
restorecon -n is not documented well: It does not report mis-labeled files u...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: policycoreutils (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-20 15:22 EDT by Dale R. Worley
Modified: 2013-09-23 15:44 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-23 15:44:25 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dale R. Worley 2013-09-20 15:22:07 EDT
Description of problem:

"restorecon -n" does not display the names of the files whose labels would be changed by "restorecon".  To get that information, you need to specify "-v" as well.  But the manual page leaves the impression that -v is not necessary.

Version-Release number of selected component (if applicable):

policycoreutils-2.1.14-46.4.fc19.x86_64

How reproducible:

reproducible

Steps to Reproduce:

1. chcon unconfined_u:object_r:default_t:s0 /common/home/worley/.config/user-dirs.dirs
2. ls -Z /common/home/worley/.config/user-dirs.dirs 
-rw-------. worley worley unconfined_u:object_r:default_t:s0 /common/home/worley/.config/user-dirs.dirs
3. restorecon -n /common/home/worley/.config/user-dirs.dirs
4. ls -Z /common/home/worley/.config/user-dirs.dirs 
-rw-------. worley worley unconfined_u:object_r:default_t:s0 /common/home/worley/.config/user-dirs.dirs
5. restorecon -nv /common/home/worley/.config/user-dirs.dirs
restorecon reset /common/home/worley/.config/user-dirs.dirs context unconfined_u:object_r:default_t:s0->unconfined_u:object_r:config_home_t:s0
6. ls -Z /common/home/worley/.config/user-dirs.dirs 
-rw-------. worley worley unconfined_u:object_r:default_t:s0 /common/home/worley/.config/user-dirs.dirs
7. restorecon /common/home/worley/.config/user-dirs.dirs
8. ls -Z /common/home/worley/.config/user-dirs.dirs 
-rw-------. worley worley unconfined_u:object_r:config_home_t:s0 /common/home/worley/.config/user-dirs.dirs

Actual results:

The "-n" simply stops restorecon from changing the labels.  To list the label changes that are "needed", "-nv" must be used.

Expected results:

I expected that "restorecon -n" will list the label changes that are "needed" instead of changing the labels.

Additional info:

restorecon normally re-labels files according to the specifications in /etc/selinux/<policy>/contexts.  The -n option is documented as:

       -n     don't change any file labels (passive check).

Because of the phrase "passive check", this naive user assumed that "restorecon -n" would output a list of files whose labels would be changed by "restorecon" (in much the same way that "make -n" tells what "make" would do, but does not do it).  It turns out that -n only suppresses changing labels, but does not cause anything to be printed in its place.  (Perhaps any errors that are encountered will be printed.)  For the effect that I wanted/expected, one must specify "restorecon -nv".

I suspect that it would be unadvisable at this late date to change the behavior of "restorecon -n" to what I expect.  Instead, it would help a great deal if the documentation of the -n option was enlarged to:

       -n     don't change any file labels (passive check).  To display
              the files whose labels would be changed, add -v.
Comment 1 Dale R. Worley 2013-09-20 15:23:02 EDT
Note:  /common/home in the above listings should be changed to /home to illustrate how the scenario would execute in a normal filesystem layout.
Comment 2 Daniel Walsh 2013-09-23 15:44:25 EDT
I will fix this in F20 and future versions.

Note You need to log in before you can comment on or make changes to this bug.