Bug 527142

Thanks for report, sounds reasonable. CC'ing upstream, as the problem exists there as well.

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)

Fixed and built as coreutils-7.6-7.fc13 , closing RAWHIDE.

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

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
Aborted

Yanko,

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
Disabled
# 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

This is rawhide i686
# uname -r
2.6.31.1-56.fc12.i686.PAE
# rpm -q coreutils
coreutils-7.6-5.fc12.i686
# 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 
Disabled
# sestatus 
SELinux status:                 disabled

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".

Created attachment 363674 [details]
aborting chcon strace

Thanks.

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".