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