Bug 527142

Summary: chcon aborts on a selinux disabled system
Product: [Fedora] Fedora Reporter: Yanko Kaneti <yaneti>
Component: coreutilsAssignee: Ondrej Vasik <ovasik>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: jim, kdudka, meyering, ovasik, twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-10-05 03:43:09 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
aborting chcon strace none

Description Yanko Kaneti 2009-10-04 18:22:22 EDT
Description of problem:
mock always runs chcon as part of it build root setup. Something along the lines of 
chcon --reference=/dev/ptmx /var/lib/mock/fedora-10-x86_64/root/dev/ptmx , ignoring an exit status or the lack of chcon.

On a selinux disabled system this aborts, leaving core files lying around.
As far as I can see chcon is of no use when running on a system with selinux disabled. Aborting seems inappropiate. Perhaps

--- a/src/chcon.c
+++ b/src/chcon.c
@@ -519,6 +519,9 @@ main (int argc, char **argv)
       usage (EXIT_FAILURE);
+  if (is_selinux_enabled () != 1)
+    error (EXIT_FAILURE, 0,_("chcon may be used only on a SELinux enabled kernel"));
   if (reference_file)
       if (getfilecon (reference_file, &ref_context) < 0)

or some similar graceful failure, like other selinux related tools.
Comment 1 Ondrej Vasik 2009-10-05 02:51:16 EDT
Thanks for report, sounds reasonable. CC'ing upstream, as the problem exists there as well.
Comment 2 Ondrej Vasik 2009-10-05 03:00:56 EDT
Personally, I would prefer this hunk - and to not hardcode program_name in runcon as well. But that's just cosmetic thing.

--- a/src/chcon.c
+++ b/src/chcon.c
@@ -519,6 +519,10 @@ main (int argc, char **argv)
       usage (EXIT_FAILURE);
+  if (is_selinux_enabled () != 1)
+    error (EXIT_FAILURE, 0,
+           _("%s may be used only on a SELinux kernel"), program_name);
   if (reference_file)
       if (getfilecon (reference_file, &ref_context) < 0)
Comment 3 Ondrej Vasik 2009-10-05 03:43:09 EDT
Fixed and built as coreutils-7.6-7.fc13 , closing RAWHIDE.
Comment 4 Jim Meyering 2009-10-05 04:12:31 EDT
thanks for the report and patch.

Yanko, can you tell me how to reproduce it?
I tried both on a bare-metal SELinux "Disabled" system and in the mock chroot on a rawhide SELinux-enabled system.  In each case, chcon did not abort.

Here's how I tried to reproduce the failure using mock:

$ mock -r fedora-10-x86_64 --init
$ SHELL=/bin/bash mock -r fedora-10-x86_64 --shell
INFO: mock.py version 0.9.17 starting...
State Changed: init plugins
State Changed: start
State Changed: lock buildroot
mock-chroot> chcon --reference=/dev/ptmx /dev/ptmx
mock-chroot> touch tmp/f
mock-chroot> chcon --reference=/dev/ptmx /tmp/f
chcon: failed to change context of `/tmp/f' to `system_u:object_r:ptmx_t:s0': Permission denied
Comment 5 Yanko Kaneti 2009-10-05 04:34:19 EDT
By selinux disabled I mean SELINUX=disabled in /etc/sysconfig/selinux 
Here it aborts. All the files on the system appear "unlabeled" 

# ls -Z /dev/ptmx 
crw-rw-rw- root tty unlabeled                        /dev/ptmx

and chcon aborts in 

      /* FIXME: this should be done exactly once, in main.  */
      context = context_new (specified_context);
      if (!context)
          abort ();

# touch /tmp/f
# chcon --reference=/dev/ptmx /tmp/f
Comment 6 Jim Meyering 2009-10-05 05:14:23 EDT

Thanks for the details.
However, what version of chcon are you using?
Please run these:

  rpm -q coreutils
  chcon --version

On a system configured like that, I get different behavior from ls -Z than what you report, as well as from chcon:

# getenforce
# touch /tmp/f
# chcon --reference=/dev/ptmx /tmp/f
chcon: failed to get security context of `/dev/ptmx': Operation not supported
[Exit 1]
# /bin/ls -Z /tmp/f
-rw-r--r-- root root ?                                /tmp/f

The above is with coreutils-7.2-4.fc11.x86_64.
With 7.6.63-addb6, ls -Z works differently:

  $ ./ls -Z /tmp/f
  ? /tmp/f

But chcon still works properly:

  # ./chcon --reference=/dev/ptmx /tmp/f
  ./chcon: failed to get security context of `/dev/ptmx': Operation not supported
Comment 7 Yanko Kaneti 2009-10-05 05:29:14 EDT
This is rawhide i686
# uname -r
# rpm -q coreutils
# chcon --version 
chcon (GNU coreutils) 7.6
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Russell Coker and Jim Meyering.
# getenforce 
# sestatus 
SELinux status:                 disabled
Comment 8 Jim Meyering 2009-10-05 09:56:24 EDT
That is odd, indeed.
Yanko, would you please run the losing chcon invocation under strace and post the log, i.e,.

touch /tmp/f
strace -o log chcon --reference=/dev/ptmx /tmp/f

Then send the file, "log".
Comment 9 Yanko Kaneti 2009-10-05 10:07:01 EDT
Created attachment 363674 [details]
aborting chcon strace
Comment 10 Jim Meyering 2009-10-05 10:28:01 EDT

That confirmed my theory:

getxattr("/dev/ptmx", "security.selinux", "unlabeled", 255) = 10

I was just remembering that there were hoops in ls.c that required
similar work-around, since getfilecon can succeed, yet produce this bogus-looking context string, "unlabeled".