Bug 146709 - policy on /opt based libs set too strict for general case
policy on /opt based libs set too strict for general case
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-31 16:54 EST by Aleksandar Milivojevic
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-01 10:21:29 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 Aleksandar Milivojevic 2005-01-31 16:54:55 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:
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.1.2.3.4).  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):
selinux-policy-targeted-1.17.30-2.19

How reproducible:
Always

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 17:07:59 EST
> mkdir -p /opt/sybase-ver/OCS-ver/lib
> touch /opt/sybase-ver/OCS-ver/lib/libxxx.so.1.2.3.4
> touch /opt/sybase-ver/OCS-ver/lib/libyyy.so 
> restorecon -R -v /opt
restorecon reset context
/opt/sybase-ver/OCS-ver/lib:root:object_r:usr_t->system_u:object_r:lib_t
restorecon reset context
/opt/sybase-ver/OCS-ver/lib/libyyy.so:root:object_r:usr_t->system_u:object_r:shlib_t
restorecon reset context
/opt/sybase-ver/OCS-ver/lib/libxxx.so.1.2.3.4:root:object_r:usr_t->system_u:object_r:shlib_t

Seems to work for me.

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

Dan
Comment 2 Daniel Walsh 2005-01-31 17:11:03 EST
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.

Dan
Comment 3 Aleksandar Milivojevic 2005-01-31 20:21:10 EST
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 10:21:29 EST
Yup, I was using old version of the package.  It is fixed in current
version.

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