Bug 146709 - policy on /opt based libs set too strict for general case
Summary: policy on /opt based libs set too strict for general case
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted   
(Show other bugs)
Version: 3
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-01-31 21:54 UTC by Aleksandar Milivojevic
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-02-01 15:21:29 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 Aleksandar Milivojevic 2005-01-31 21:54:55 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:
Policy file for /opt libs is not consistent.  For shared libs ending
in *.so, it will label them as system_u:object_r:shlib_t if found
anywhere in /opt.  For all other shared libs (for example
libfoobar.so.1.2.3), they will be marked as system_u:object_r:shlib_t
only if they are found in /opt/one-level/lib directories.

This breaks some 3rd party packages, such as for example Sybase
libraries (located in /opt/sybase-ver/OCS-ver/lib).  Couple of files
ending with .so will be labeled correctly, but the rest of the
libraries will not be labled as shared libraries (since they are
called libxxx.so.  Because of this, when I built Sybase PHP
module, Apache was not able to load Sybase library required by the
module on startup.

Also, from time to time I used to run into 3rd party packages that
like to install into /opt/package/version kind of directory structure.
 They would suffer from the same problem.

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

How reproducible:

Steps to Reproduce:
1. create /opt/one/two/lib
2. place shared library ending with version (libfoobar.so.1.2.3)
3. have apache dynamically load the library

Additional info:

Comment 1 Daniel Walsh 2005-01-31 22:07:59 UTC
> mkdir -p /opt/sybase-ver/OCS-ver/lib
> touch /opt/sybase-ver/OCS-ver/lib/libxxx.so.
> touch /opt/sybase-ver/OCS-ver/lib/libyyy.so 
> restorecon -R -v /opt
restorecon reset context
restorecon reset context
restorecon reset context

Seems to work for me.

I agree if you don't put *.so.* file in a  directory with lib this
will not work.


Comment 2 Daniel Walsh 2005-01-31 22:11:03 UTC
If I change file context to be
< /opt/.*/lib(64)?/.*\.so(\.[^/]*)*     --      system_u:object_r:shlib_t
> /opt/.*\.so(\.[^/]*)* --      system_u:object_r:shlib_t

That should fix it.  As long as there is never a /opt/tmp this should
be ok.


Comment 3 Aleksandar Milivojevic 2005-02-01 01:21:10 UTC
I'm looking at my home system right now, and it seems that it has
newer version of selinux-policy-targeted than the system where I had
problems.  /opt section looks completely rewritten.  It might be that
this was already resolved.  I'll try it out tomorrow morning when I
get back to work, and if that is the case, I'll report back and close
this as resolved/currentrelease.  Sorry for the trouble, I should have
checked if I had latest version of package before reporting...

Comment 4 Aleksandar Milivojevic 2005-02-01 15:21:29 UTC
Yup, I was using old version of the package.  It is fixed in current

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