Bug 114067 - libselinux-1.4-1 to libselinux-1.4-6 broke installwatch.so
Summary: libselinux-1.4-1 to libselinux-1.4-6 broke installwatch.so
Alias: None
Product: Fedora
Classification: Fedora
Component: libselinux   
(Show other bugs)
Version: rawhide
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-01-22 06:48 UTC by Ville Herva
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: 2004-02-11 16:05:19 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
make open() and fopen() work with library constructors (1012 bytes, patch)
2004-06-01 20:21 UTC, Hans Ecke
no flags Details | Diff
Fix to last patch: fopen() does not return integers (oops) (1014 bytes, patch)
2004-06-01 20:28 UTC, Hans Ecke
no flags Details | Diff

Description Ville Herva 2004-01-22 06:48:53 UTC
Description of problem:
libselinux-1.4-1 to libselinux-1.4-6 broke installwatch.so 

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

How reproducible:

Steps to Reproduce:
 root@babbage:/>rpm -q checkinstall glibc coreutils libselinux
 root@babbage:/>LD_PRELOAD=/usr/local/lib/installwatch.so cp
/etc/issue /tmp/FOOO
 root@babbage:/backup-versioned>chroot 2003-12-21T052000
 root@babbage:/>rpm -q checkinstall glibc coreutils libselinux
 root@babbage:/>LD_PRELOAD=/usr/local/lib/installwatch.so cp
/etc/issue /tmp/FOOO
 zsh: segmentation fault  LD_PRELOAD=/usr/local/lib/installwatch.so cp
/etc/issue /root/FOOO

Additional info:
CheckInstall is a product that monitors software installation ("make
install" for instance) and records the copied files. Using this
information, it creates an RPM, DEP or slackware packed. It includes
installwatch.so that is used with preloading
(LD_PRELOAD=/usr/local/lib/installwatch.so) for the actual monitoring.

Basically everything that depends on /lib/libselinux.so.1 (things like
cp, mkdir, mv etc etc) no longer work on Fedora Core unstable
installation when run with LD_PRELOAD=/usr/local/lib/installwatch.so.
The result is segmentation fault.

I traced it back to upgrade from libselinux-1.4-1 to libselinux-1.4-6
(see steps to reproduce).

So with libselinux-1.4-1, it works, with 1.4-6 is broken. I tried
tried building checkinstall-1.6.0beta3 from source, but its
installwatch.so shows the same behaviour.

I'm running a kernel (2.4.21-jam1+security_fixes) that doesn't include
selinux fwiw. Nothing else wrt. glibc, coreutils or libselinux seems
broken on this installation.

Comment 1 Ville Herva 2004-01-22 07:16:07 UTC
Additional note: I tried copying the libselinux-1.4-1 versions of
/lib/libselinux.so.1 to /lib, and this fixes the current installation
wrt. checkinstall. So it is really libselinux that makes the
difference (/bin/cp does depend on other libraries, too).

Comment 2 Ville Herva 2004-01-23 14:43:04 UTC
I asked about this on the selinux mailing list, too. Stephen Smalley 
answered (forwarded with his permission):                            
Date:   Fri, 23 Jan 2004 08:05:38 -0500                              
From:   Stephen Smalley <sds@epoch.ncsc.mil>                         
Subject: Re: libselinux upgrade from 1.4-1 to 1.4-6 broke
On Fri, 2004-01-23 at 02:00, Ville Herva wrote:                      
> Also, I added this bug to redhat bugzilla:                         
> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=114067         
> So if anybody is interested enough, comments can be added there,
Yes, Dan Walsh brought this to my attention, and I looked into it and
sent him an explanation yesterday.  I used strace -f on installwatch
see where it fails, and then did some further debugging.  The relevant
change to libselinux is the addition of the init_selinuxmnt()        
constructor function, which does an open("/proc/mounts", O_RDONLY) to
find the selinuxfs mount point at runtime (RH asked that we add this 
rather than hardcoding the path to the selinuxfs mount point, so that
they can change the mount point later without impacting existing
installwatch intercepts the open, and then subsequently tries to call
true_open, which is supposed to refer to the real open function, but 
true_open seems to be NULL at this point.  So installwatch doesn't
to be able to handle calls performed from library constructors, which
would seem to be a defect in installwatch.                           
Stephen Smalley <sds@epoch.ncsc.mil>                                 
National Security Agency                                             
He also had this patch:                                              
By the way, for what it is worth, the below patch to installwatch will
allow it to continue functioning with libselinux.  But this doesn't  
solve the general problem, i.e. same issue could arise for any of the
intercepted calls if a library invokes them from a constructor.      
--- installwatch-0.6.3.orig/installwatch.c      2001-12-22
+++ installwatch-0.6.3/installwatch.c   2004-01-23 08:44:55.757509190
@@ -572,6 +572,12 @@                                                 
        int result;                                                  
        char canonic[MAXPATHLEN];                                    
+       if (!true_open) {                                            
+               true_open = dlsym(RTLD_NEXT, "open");                
+               if (!true_open)                                      
+                       return -1;                                   
+       }                                                            
        va_start(ap, flags);                                         
        mode = va_arg(ap, mode_t);                                   
Stephen Smalley <sds@epoch.ncsc.mil>                                 
National Security Agency                                             

Comment 3 Daniel Walsh 2004-02-11 14:20:17 UTC
Fixed in rawhide.

Comment 4 Ville Herva 2004-02-11 14:33:49 UTC
Out of interest: how was it fixed? In selinux or checkinstall? (I
don't think rawhide even includes checkinstall?)

Comment 5 Daniel Walsh 2004-02-11 16:04:52 UTC
Woops put the wrong status.  THis should be marked as not a bug.  The
bug is in checkinstall which we don't ship.

Comment 6 Hans Ecke 2004-06-01 20:19:57 UTC
The above patch to open() is not enough for me, I also need to patch 
fopen(). Patch attached below and works for me. 

Comment 7 Hans Ecke 2004-06-01 20:21:48 UTC
Created attachment 100761 [details]
make open() and fopen() work with library constructors

Comment 8 Hans Ecke 2004-06-01 20:28:40 UTC
Created attachment 100764 [details]
Fix to last patch: fopen() does not return integers (oops)

Sorry about the spam, this is the corrected version.

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