Re: [PATCH]: chcon: no longer abort on SELinux disabled kernel

[Jim Meyering]

Ondřej Vašík wrote:
> as reported in https://bugzilla.redhat.com/show_bug.cgi?id=527142 by
> Yanko Kaneti, chcon aborts on SELinux disabled kernel due to missing
> check for SELinux enabled kernel. Attached patch is fixing the issue.
>
> Additionally - for consistency - error message of this check in runcon
> was changed to not hardcode "runcon" program name.

[Cc'ing the SELinux list for the question at the end
 Summary: chcon(1) aborts when a successful getfilecon
 result is passed to context_new and makes it return NULL. ]

Thanks, Ondřej.
At first, I planned to use that patch, mostly as-is, but
moving the chcon paragraph in NEWS "up" so that it's alphabetized.

  chcon no longer aborts on SELinux disabled system.
  [the bug dates back to the initial implementation]

However, since I have so far been unable to reproduce the failure,
(neither in mock, nor on bare-metal x86_64 with SELinux disabled)
and know that merely running chcon with SELinux disabled is not
enough to trigger the abort, what's written above is misleading.
What if the only way to trigger the abort is with a strangely-
or improperly-configured system?
In fact, until I understand how/why the offending code is being
reached, I hesitate to call this a bug or say where it originated.

If the getfilecon call succeeds, then why would context_new fail?
Right after I wrote the line above, it clicked.
Some versions of getfilecon can succeed (and return >= 0)
yet set the context string to "unlabeled".  *That* is what
causes trouble if you pass it to context_new.

This makes me want to write a getfilecon wrapper
that would convert that surprising result into a return
value of -1 with errno of ENOTSUP.  A wrapper would also
protect us from the small risk of folks using the older
libselinux versions that can return 0 and a NULL context.

Can the SELinux folks tell us under what circumstances
getfilecon will return 10 and set *context to "unlabeled"?

Thanks,

Jim