Bug 559451 - chcon aborts
chcon aborts
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: coreutils (Show other bugs)
19
All Linux
low Severity medium
: ---
: ---
Assigned To: Kamil Dudka
Fedora Extras Quality Assurance
: Patch
: 574068 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-01-28 01:33 EST by Ralf Corsepius
Modified: 2013-12-19 14:07 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-19 14:07:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
proposed fix (531 bytes, patch)
2010-03-16 14:36 EDT, Kamil Dudka
no flags Details | Diff

  None (edit)
Description Ralf Corsepius 2010-01-28 01:33:01 EST
Description of problem:
chcon dumps core

Version-Release number of selected component (if applicable):
coreutils-7.6-9.fc12.x86_64

How reproducible:
Always

Steps to Reproduce:
1. mock -r fedora-12-x86_64 init

Then check /var/log/messages and /var/cache/abrt/
  
Actual results:

abrt generates a /var/cache/abrt/ccpp* (comprising a coredump) indicating
"chcon --reference=/dev/null /var/lib/mock/fedora-12-x86_64/root/dev/null"
has dumped core.

Due to the limitations of abrt (Likely a uid issue; the uid this chcon call is being run under doesn't match the interactive user), this report is never being reported to abrt-gui.

Expected results:

* chcon not to dump core.

* abrt to report this issue to the user having launched mock.


Additional info:
* This is on a system with SELinux disabled (No idea if this is of any importance).

* This bug is what triggers
https://bugzilla.redhat.com/show_bug.cgi?id=559439
Core was generated by `chcon --reference=/dev/null /var/lib/mock/fedora-12-x86_64/root/dev/null'.


* Traceback: 
...
Program terminated with signal 6, Aborted.
#0  0x0000003b0e0326c5 in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64	  return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb) where
#0  0x0000003b0e0326c5 in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x0000003b0e033ea5 in abort () at abort.c:92
#2  0x0000000000402de4 in change_file_context (argc=<value optimized out>, argv=<value optimized out>) at chcon.c:179
#3  process_file (argc=<value optimized out>, argv=<value optimized out>) at chcon.c:287
#4  process_files (argc=<value optimized out>, argv=<value optimized out>) at chcon.c:324
#5  main (argc=<value optimized out>, argv=<value optimized out>) at chcon.c:565

Interestingly, this traceback tells this is being caused by SIGABRT ("signal 6") and not a SIGSEGV ("signal 11").
Comment 1 Kamil Dudka 2010-01-28 06:53:55 EST
Thanks for filling the bug!  It dies on failure of context_new() within change_file_context():

  context = context_new (specified_context);
  if (!context)
    abort ();

Looking into context_new() the only reason of the failure may be a parse error (not counting the OOM state).  Could you please stop a debugger within change_file_context() and print the value of 'specified_context' in the failing case?

$ gdb -q --args chcon --reference=/dev/null /var/lib/mock/fedora-12-x86_64/root/dev/null

(gdb) break change_file_context
(gdb) run
(gdb) print specified_context
(gdb) continue
Comment 2 Kamil Dudka 2010-01-28 07:04:23 EST
> (gdb) break change_file_context

change_file_context() may be optimized out because of the 'static' keyword, please use context_new() for the break-point instead:

(gdb) break context_new

> (gdb) run
> (gdb) print specified_context
> (gdb) continue
Comment 3 Ralf Corsepius 2010-01-28 08:29:55 EST
This is what I see in gdb, right before the call to abort():

(gdb) where
#0  change_file_context (argc=<value optimized out>, argv=<value optimized out>) at chcon.c:179
#1  process_file (argc=<value optimized out>, argv=<value optimized out>) at chcon.c:287
#2  process_files (argc=<value optimized out>, argv=<value optimized out>) at chcon.c:324
#3  main (argc=<value optimized out>, argv=<value optimized out>) at chcon.c:565
(gdb) print specified_context
$5 = 0x60f140 "unlabeled"
(gdb) print context
$6 = (context_s_t *) 0x0


Checking chcon.c (single stepping in gdb):

22	context_t context_new(const char *str)
23	{
24		int i, count;
25		context_private_t *n =
26		    (context_private_t *) malloc(sizeof(context_private_t));
27		context_t result = (context_t) malloc(sizeof(context_s_t));
28		const char *p, *tok;
29	
30		if (result)
31			result->ptr = n;
32		else
33			free(n);
34		if (n == 0 || result == 0) {
35			goto err;
36		}
37		n->current_str = n->component[0] = n->component[1] = n->component[2] =
38		    n->component[3] = 0;
39		for (i = count = 0, p = str; *p; p++) {
40			switch (*p) {
41			case ':':
42				count++;
43				break;
44			case '\n':
45			case '\t':
46			case '\r':
47				goto err;	/* sanity check */
48			case ' ':
49				if (count < 3)
50					goto err;	/* sanity check */
51			}
52		}
53		/*
54		 * Could be anywhere from 2 - 5
55		 * e.g user:role:type to user:role:type:sens1:cata-sens2:catb
56		 */
57		if (count < 2 || count > 5) {	/* might not have a range */
58			goto err;
59		}

I am observing the for-loop (starting at line 39) to iterating over str="unlabeled", ending up with "count = 0", which then causes the "goto err" on line 58 to hit.

=> abort => boom.
Comment 4 Kamil Dudka 2010-01-28 09:03:45 EST
Thanks for the trace!  That's exactly what I needed to know.  The function context_new() simply expects a valid security context as the argument.  However it gets "unlabeled" and therefor has to fail.  The value must have been obtained from getfilecon().

  if (reference_file)
    {
      if (getfilecon (reference_file, &ref_context) < 0)
        error (EXIT_FAILURE, errno, _("failed to get security context of %s"),
               quote (reference_file));

      specified_context = ref_context;
    }

It means getfilecon() succeeds, though it returns an invalid context.  We should be able to detect such situation.  I am only not sure if the exact match for "unlabeled" is the proper (and enough generic) way to fix it.
Comment 5 Kamil Dudka 2010-01-28 09:15:04 EST
I can see we have the same hack in ls.c already:

  if (err == 0)
    have_selinux = ! STREQ ("unlabeled", f->scontext);
Comment 6 Kamil Dudka 2010-03-16 10:33:06 EDT
*** Bug 574068 has been marked as a duplicate of this bug. ***
Comment 7 matt 2010-03-16 11:48:27 EDT
Hello, I am coming from dupe bug #574068 (via abrt).  Kamil asked me for the ouput of:

# chcon --reference=/etc/cups/ppd/S600.ppd /etc/cups/ppd/S600.ppd.new

and the result is:

chcon: cannot access `/etc/cups/ppd/S600.ppd.new': No such file or directory

So then I:

# cp /etc/cups/ppd/S600.ppd  /etc/cups/ppd/S600.ppd.new
# chcon --reference=/etc/cups/ppd/S600.ppd /etc/cups/ppd/S600.ppd.new

and get:

Aborted (core dumped)

And abrtd logs where the core dump is stored.  So, then:

# gdb /usr/bin/chcon /var/cache/abrt/ccpp-1268753890-5269/coredump
GNU gdb (GDB) Fedora (7.0.1-34.fc12)
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.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/chcon...(no debugging symbols found)...done.
Reading symbols from /lib/libselinux.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libselinux.so.1
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Core was generated by `chcon --reference=/etc/cups/ppd/S600.ppd /etc/cups/ppd/S600.ppd.new'.
Program terminated with signal 6, Aborted.
#0  0x00141424 in __kernel_vsyscall ()
Missing separate debuginfos, use: debuginfo-install coreutils-7.6-9.fc12.i686
(gdb) bt
#0  0x00141424 in __kernel_vsyscall ()
#1  0x00b92a91 in raise () from /lib/libc.so.6
#2  0x00b9435a in abort () from /lib/libc.so.6
#3  0x0804aa7d in fdopendir ()
#4  0x00b7ebb6 in __libc_start_main () from /lib/libc.so.6
#5  0x08049461 in fdopendir ()
(gdb)


NOTE:  In case it matters, like Ralf, I have SELinux disabled (SELINUX=disabled in /etc/sysconfig/selinux).
Comment 8 Kamil Dudka 2010-03-16 14:36:11 EDT
Created attachment 400530 [details]
proposed fix

Thank you for the feedback!  It's really appreciated since I wasn't successful in reproducing the crash myself.  I've also tried to disable SELinux and got a regular failure of chcon, but no crash.

FWIW the attached patch should fix it.  I've also prepared a scratch build of coreutils with the patch applied for testing purposes:

http://koji.fedoraproject.org/koji/taskinfo?taskID=2056516

Thanks in advance for testing!
Comment 9 Kamil Dudka 2010-09-28 05:58:27 EDT
The patch is here, but I haven't been successful in reproducing the issue yet, will try it again later.  If anybody is facing the bug and was able/willing to test an updated package of coreutils, it would speed up the resolution.
Comment 10 Fedora End Of Life 2013-04-03 16:07:01 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 11 Ondrej Vasik 2013-12-18 17:04:11 EST
Kamil, I see the patch was never applied to Fedora Rawhide - have you tried to propose it upstream?
Comment 12 Kamil Dudka 2013-12-19 11:42:31 EST
Nope.  I did not have any reproducer and nobody has confirmed that it actually fixes the issue.  I would close this bug as INSUFFICIENT_DATA...
Comment 13 Ondrej Vasik 2013-12-19 14:07:48 EST
I agree... feel free to reopen if you experience the issue again.

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