Bug 273081 - can't safely call matchpathcon() from a library
can't safely call matchpathcon() from a library
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: libselinux (Show other bugs)
5.0
All All
high Severity medium
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-31 15:41 EDT by Nalin Dahyabhai
Modified: 2012-01-24 03:04 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-20 17:03:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nalin Dahyabhai 2007-08-31 15:41:00 EDT
If a library calls matchpathcon(), error messages which matchpathcon() prints,
unconditionally, to descriptor 2 can interfere with the application which uses
the library.  For example if that application's been started by xinetd, in which
case descriptor 2 is a network connection, outputting the error breaks the
network protocol.

The library can't "know" if using set_matchpathcon_printf() to disable this
behavior is safe because it has no way to determine if the application has
already done so.
Comment 1 Daniel Walsh 2007-09-18 11:39:36 EDT
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
Comment 2 Stephen Smalley 2007-09-19 10:07:52 EDT
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?
Comment 3 Daniel Walsh 2007-09-19 10:38:39 EDT
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?
Comment 4 Stephen Smalley 2007-09-19 10:52:06 EDT
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.
Comment 5 Nalin Dahyabhai 2007-09-19 10:57:30 EDT
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.
Comment 6 Stephen Smalley 2007-09-19 11:28:54 EDT
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).
Comment 7 RHEL Product and Program Management 2007-10-19 16:26:41 EDT
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.
Comment 8 RHEL Product and Program Management 2008-06-02 16:32:47 EDT
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.
Comment 9 Daniel Walsh 2008-09-17 14:16:45 EDT
Fixed in libselinux-1.33.4-5.1.el5
Comment 10 RHEL Product and Program Management 2008-09-17 14:24:39 EDT
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.
Comment 15 errata-xmlrpc 2009-01-20 17:03:32 EST
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

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