Bug 142644 - hard to use libraries installed to /usr/local/lib
Summary: hard to use libraries installed to /usr/local/lib
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc   
(Show other bugs)
Version: 3
Hardware: All Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
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:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-13 13:56:44 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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:
setenforce 0
make install
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

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

How reproducible:

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.)


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