Bug 142644 - hard to use libraries installed to /usr/local/lib
Summary: hard to use libraries installed to /usr/local/lib
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: 3
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-12-11 12:07 UTC by Paul Osmialowski
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2004-12-13 13:56:44 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Paul Osmialowski 2004-12-11 12:07:05 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
First of all, RHL, RHEL and FC are the only distros I know that do not
have /usr/local/lib entry in /etc/ld.so.conf file! Always, after fresh
installation first thing that I do is to add such line there. The new
problem is that in FC3 SELinux does not allow ldconfig to handle
libraries installed there properly. At first, I was installing tarball
libraries that way:
./configure
make
setenforce 0
make install
ldconfig
setenforce 1
Unfortunately, after installation of few libraries, setenforce 0
didn't help to run ldconfig properly anymore! I had to disable SELinux
completly on my desktop PC, but it can be real problem if I run FC3 on
server.


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Download any tarball with library
2. configure, make and install it
3. run ldconfig
    

Actual Results:  ldconfig writes error messages (If you're working on
X, look at dmesgs to see that it's because of SELinux activity)

Expected Results:  Proper behavior

Additional info:

Comment 1 Jakub Jelinek 2004-12-12 20:11:58 UTC
/usr/local/lib not in /etc/ld.so.conf is on purpose.
As for the SELinux related problems, this is because the libraries aren't
system_u:object_r:shlib_t as they ought to, but root:object_r:lib_t or something
like that.  Certainly restorecon /usr/local/lib/lib*.so* ought to fix this, but
whether and why you need to run this is something selinux policy maintainers
need to answer.

Comment 2 Daniel Walsh 2004-12-13 13:52:02 UTC
SELinux does not handle the labeling of shared libraries installed or
copied/moved outside of RPM.  File contexts will default to the context of the
directory they are installed into.  So in this case they are defaulting to
lib_t.  The only thing that you can do is do a restorecon after the install to
set them to the proper security context of shlib_t.  (You could also use chcon
which is similar to chmod. but often restorecon is easier.)

Dan


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