Bug 273081

Updated libselinux in Rawhide to use syslog libselinux-2.0.33-2.fc8

Will test for a couple of weeks and make sure we get upstream approval before
back porting.  This should not be a problem unless the file_contexts gets messed up.

I propose this goes out in 5.2

There is some concern with making this change upstream (as discussed on selinux
list) as it changes behavior of an existing interface, and we already provide a
way to change the default behavior via set_matchpathcon_printf.  So while I'm
not unalterably opposed to changing it, I'd tend to prefer instead adding a
get_matchpathcon_printf or similar function to let the library test to see
whether the application has already overridden the default (and if so, save that
function pointer for later restoration), and then have the library use
set_matchpathcon_printf around its use of matchpathcon.  Does that sound
reasonable or is it too onerous on the users of matchpathcon?

I would think the change required would be to only change it if the default
printf call was still in effect.  So how would you tell if the default printf
had been changed?

I was thinking that the library would unconditionally get and save the current
function pointer (get_matchpathcon_printf), set the active one to its own
internal function that uses syslog or whatever (set_matchpathcon_printf), use
matchpathcon, and then set the active on back to the saved original function
pointer before returning.

Or if you like, the get_matchpathcon_printf function could instead return NULL
if the current one is the default printf function so that the caller can tell
whether it has been set or not, and the caller would only invoke
set_matchpathcon_printf if the returned value was NULL.

The library from which I'm calling matchpathcon() is supposed to be
thread-safe, so while save/restore would probably work, I'd never
be sure it wasn't messing with the app.

Ok, although I don't think matchpathcon in libselinux 1.x is thread-safe anyway
(due to invoking matchpathcon_init on first call to load in the file contexts
specification and loading that into global state for the library).  It would
need to use the pthread_once idiom or mark the various bits of global state with
__thread to make them per-thread.  In libselinux 2.x, matchpathcon is obsoleted
by the selabel interfaces although the interface is still provided (just
reimplemented internally by them), and that should be thread safe (per-handle
state, and the global handle for the legacy matchpathcon interfaces is marked
with __thread).

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Fixed in libselinux-1.33.4-5.1.el5

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-0210.html