Bug 758251 - Missing dependencies and wrong arch
Summary: Missing dependencies and wrong arch
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Panu Matilainen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-11-29 16:09 UTC by Mads Kiilerich
Modified: 2012-02-11 22:04 UTC (History)
6 users (show)

Fixed In Version: rpm-4.9.1.2-5.fc16
Clone Of:
Environment:
Last Closed: 2012-02-11 21:55:20 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Mads Kiilerich 2011-11-29 16:09:33 UTC
policycoreutils-sandbox-2.1.4-10.fc16.i686 /usr/sbin/seunshare will dynamically load libcgroup.so.1 and libcap-ng.so.0 . It is apparently done in some tricky way so ldd and the rpm auto dependencies can't detect it.

(
policycoreutils-python-2.1.4-10.fc16.i686 do however have an apparently unused and un-arch'ed "libcgroup" requirement - perhaps to make the libcgroup dependency optional?

I don't see any obvious chain for pulling in libcap-ng.
)

However: in both cases it is possible on a multilib system to get the requirements fulfilled by something of the wrong arch that doesn't work.

As far as I can see policycoreutils-sandbox should have an explicit isa dependency to libcgroup and libcap-ng.

Comment 1 Daniel Walsh 2011-11-29 20:45:48 UTC
Bill do you agree?

Comment 2 Bill Nottingham 2011-11-29 20:58:09 UTC
Yes. Although just having the binary have the proper DT_NEEDED seems way simpler.

Comment 3 Daniel Walsh 2011-11-30 17:12:44 UTC
The command we are compiling this with is.

cc  -o seunshare seunshare.o -lcgroup -lselinux -lcap-ng -L/usr/lib64

Is there something wrong here?  I guess the -L could be moved forward?

Comment 4 Daniel Walsh 2011-11-30 17:17:02 UTC
 ldd /usr/sbin/seunshare 
	linux-vdso.so.1 =>  (0x00007fffca5ff000)
	libcgroup.so.1 => /lib64/libcgroup.so.1 (0x00007faaf6837000)
	libselinux.so.1 => /lib64/libselinux.so.1 (0x00007faaf6617000)
	libcap-ng.so.0 => /lib64/libcap-ng.so.0 (0x00007faaf6411000)
	libc.so.6 => /lib64/libc.so.6 (0x00007faaf6058000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007faaf5e3c000)
	/lib64/ld-linux-x86-64.so.2 (0x0000003b43000000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007faaf5c37000)

Something wrong here?

Comment 5 Bill Nottingham 2011-11-30 18:31:16 UTC
-> rpm

RPM apparently isn't reading DT_NEEDEDs from setuid binaries. Why?

Comment 6 Daniel Walsh 2011-11-30 19:12:15 UTC
I confirmed this.  If I remove the setuid from the make install within the package, everything works correctly.

Comment 7 Mads Kiilerich 2011-11-30 19:34:49 UTC
It took me some time to understand dwalsh's comment.

policycoreutils-2.1.8/sandbox/Makefile has
        install -m 4755 seunshare $(SBINDIR)/
and ldd will thus fail.

The spec do however have 
%attr(0755,root,root) %caps(cap_setpcap,cap_setuid,cap_fowner,cap_dac_override,cap_sys_admin,cap_sys_nice=pe) %{_sbindir}/seunshare
and the file will thus be installed without suid bit. It seems like it works correctly anyway (because of caps?), so I guess the whole suid could be removed completely.

It could be argued that rpmbuild should remove all suid flags before running ldd ... or that ldd should work with suids. IMHO it is ok to require that packages don't install files suid in %install but only specify it in %files. In that case rpmbuild should fail if it finds any suid binaries that it can't process.

Comment 8 Daniel Walsh 2011-11-30 20:06:29 UTC
Well the problem with that is 

make install 

In a lot of packages installs the apps with 5755, and having maintainers patching this out seems painful.

Comment 9 Mads Kiilerich 2011-12-01 00:38:35 UTC
notting pointed out on irc that ldd does work with suids.

We will thus get the right dependencies with
  echo /usr/sbin/seunshare | /usr/lib/rpm/redhat/find-requires

This helper is however not used because we have
  /usr/lib/rpm/macros:%_use_internal_dependency_generator	1

Adding
  %define _use_internal_dependency_generator 0
to the spec generates an rpm with the right dependencies.

rpm-build's internal dependency generator will call elfutils directly. This way of doing it generally works correctly, as shown by
  echo /usr/sbin/seunshare | /usr/lib/rpm/elfdeps --requires

It seems like it for some reason doesn't work inside rpm ... or that there is something else wrong ...

Comment 10 Panu Matilainen 2011-12-01 05:18:25 UTC
It's just a stupid bug in rpm, incidentally I just spotted it two days ago:
http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=87d9e3c4adac92ff544440dd1239a4ae4fe05bb4

Comment 11 Panu Matilainen 2011-12-01 07:36:00 UTC
Fixed in rawhide now (rpm-4.9.1.2-6.fc17), but both f16 and f15 will need updates too.

Comment 12 Fedora Update System 2012-02-09 08:54:36 UTC
rpm-4.9.1.2-5.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/rpm-4.9.1.2-5.fc16

Comment 13 Fedora Update System 2012-02-09 08:57:25 UTC
rpm-4.9.1.2-4.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/rpm-4.9.1.2-4.fc15

Comment 14 Fedora Update System 2012-02-10 00:56:15 UTC
Package rpm-4.9.1.2-5.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing rpm-4.9.1.2-5.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-1504/rpm-4.9.1.2-5.fc16
then log in and leave karma (feedback).

Comment 15 Fedora Update System 2012-02-11 21:55:20 UTC
rpm-4.9.1.2-5.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 16 Fedora Update System 2012-02-11 22:04:05 UTC
rpm-4.9.1.2-4.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.


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