Description of problem: libselinux-1.4-1 to libselinux-1.4-6 broke installwatch.so Version-Release number of selected component (if applicable): libselinux-1.4-6 How reproducible: Always Steps to Reproduce: root@babbage:/>rpm -q checkinstall glibc coreutils libselinux checkinstall-1.5.3-1 glibc-2.3.3-1 coreutils-5.0-35 libselinux-1.4-1 root@babbage:/>LD_PRELOAD=/usr/local/lib/installwatch.so cp /etc/issue /tmp/FOOO root@babbage:/>^D root@babbage:/backup-versioned>chroot 2003-12-21T052000 root@babbage:/>rpm -q checkinstall glibc coreutils libselinux checkinstall-1.5.3-1 glibc-2.3.3-1 coreutils-5.0-35 libselinux-1.4-6 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. See: http://asic-linux.com.mx/~izto/checkinstall/index.php 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.
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).
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.mil> Subject: Re: libselinux upgrade from 1.4-1 to 1.4-6 broke installwatch.so 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, too. 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 to 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 code). 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 seem to be able to handle calls performed from library constructors, which would seem to be a defect in installwatch. -- Stephen Smalley <sds.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 18:37:06.000000000 +-0500 +++ installwatch-0.6.3/installwatch.c 2004-01-23 08:44:55.757509190 -0500 @@ -572,6 +572,12 @@ int result; char canonic[MAXPATHLEN]; + if (!true_open) { + true_open = dlsym(RTLD_NEXT, "open"); + if (!true_open) + return -1; + } + REFCOUNT; va_start(ap, flags); mode = va_arg(ap, mode_t); -- Stephen Smalley <sds.mil> National Security Agency ------------------------------------------------------------------------
Fixed in rawhide.
Out of interest: how was it fixed? In selinux or checkinstall? (I don't think rawhide even includes checkinstall?)
Woops put the wrong status. THis should be marked as not a bug. The bug is in checkinstall which we don't ship.
The above patch to open() is not enough for me, I also need to patch fopen(). Patch attached below and works for me.
Created attachment 100761 [details] make open() and fopen() work with library constructors
Created attachment 100764 [details] Fix to last patch: fopen() does not return integers (oops) Sorry about the spam, this is the corrected version.