Bug 142644 - hard to use libraries installed to /usr/local/lib
hard to use libraries installed to /usr/local/lib
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-11 07:07 EST by Paul Osmialowski
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-12-13 08:56:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Paul Osmialowski 2004-12-11 07:07:05 EST
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 15:11:58 EST
/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 08:52:02 EST
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.