I was running revdep-rebuild and one of the packages with broken dependencies was libdv. revdep-rebuild began to re-emerge libdv and, when making the executable file, this error appeared: making executable: /usr/lib/libdv.so.4.0.0 QA Notice: the following files contain insecure RUNPATH's Please file a bug about this at http://bugs.gentoo.org/ For more information on this issue, kindly review: http://bugs.gentoo.org/81745 /var/tmp/portage/libdv-0.102/image//usr/lib usr/bin/dubdv /var/tmp/portage/libdv-0.102/image//usr/lib usr/bin/encodedv /var/tmp/portage/libdv-0.102/image//usr/lib usr/bin/playdv
emerge info: Portage 2.0.53 (default-linux/x86/2005.0, gcc-3.3.6, glibc-2.3.5-r1, 2.6.11-gentoo-r6 i686) ================================================================= System uname: 2.6.11-gentoo-r6 i686 AMD Athlon(tm) XP 1700+ Gentoo Base System version 1.6.13 distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [disabled] dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.8.1-r1, 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -pipe -march=athlon-xp -fomit-frame-pointer -fforce-addr -frerun-loop-opt -floop-optimize -frerun-cse-after-loop -falign-functions=4" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -pipe -march=athlon-xp -fomit-frame-pointer -fforce-addr -frerun-loop-opt -floop-optimize -frerun-cse-after-loop -falign-functions=4" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://linuv.uv.es/mirror/gentoo ftp://ftp.rediris.es/pub/linux/distributions/gentoo ftp://ftp.gentoo-pt.org/pub/gentoo/ ftp://mir.zyrianes.net/gentoo/ ftp://ftp.caliu.info/pub/gentoo/ http://mir.zyrianes.net/gentoo/" LANG="es_ES.UTF-8" LC_ALL="es_ES.UTF-8" LINGUAS="es en ja" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dnow X acpi alsa apache2 audiofile avi bash-completion bidi bitmap-fonts browserplugin bzip2 bzlib canna cdr cjk crypt cups curl dga directfb divx4linux doc dvb dvd dvdr eds emboss encode esd ethereal evo exif expat fam fbcon ffmpeg fftw flac foomaticdb freewnn ftp gb gcj gd gdbm gif glut gmp gnome gstreamer gtk gtk2 gtkhtml hal iconv idn imagemagick imlib iodbc java jikes jpeg lcms libg++ libwww mad memlimit mikmod mime mmx mng motif mozilla mp3 mpeg msn nas nls nptl odbc offensive ogg oggvorbis openal opengl pam pcre pdflib perl png pnp posix ppds quicktime readline samba sdl sharedmem simplexml spell ssl svg svga sysvipc szip tcltk tcpd tetex theora threads tiff truetype truetype-fonts type1-fonts udev unicode usb userlocales videos vorbis wmf x86 xml xmms xv xvid zlib video_cards_nvidia linguas_es linguas_en linguas_ja userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LDFLAGS, PORTDIR_OVERLAY
mholzer, pls provide fixed ebuilds. d'oh, rpath issues are becoming a serious annoyance ...
can you test 0.104 ?
(In reply to comment #2) > d'oh, rpath issues are becoming a serious annoyance ... I expect that with the recent addition of the pax-utils depend to portage we are going to see a flood of them for a month or two then hopefully we will see it slow down then trickle away to almost never again.
Any chance we could make this warning non-blocking (or easily unblockable) ? I don't mind the bugs so that we remember to fix it (although I would prefer to file them in a specific subcomponent) but they are usually minor risk (group portage needed) and their resolution delays are a little too large...
(In reply to comment #3) > can you test 0.104 ? > Hum... I tried with 0.104-r1 and it worked perfectly... But still I have a problem that (I thoght) could be related with this issue: new packages are apparently being installed with absolute references to files that belong to the same package; this causes problems after merging into /, since the path isn't right. What I mean is, to mention a couple of examples, that gnome-terminal points to /var/tmp/portage/gnome-terminal-2.10.0/image//usr/share/gnome-terminal/glade/gnome-terminal.glade2 where that file's right path is /usr/share/gnome-terminal/glade/gnome-terminal.glade2 And the same happened with gnome-games, shall I report a new bug with this? Is it a problem of my configuration? Is it related with the RUNPATH problem (since it also included the path of the compilation dir)?
(In reply to comment #5) > Any chance we could make this warning non-blocking (or easily unblockable) ? We could but I dont think that it would be a very wise or responsible thing todo for a distro. > I don't mind the bugs so that we remember to fix it (although I would prefer > to file them in a specific subcomponent) but they are usually minor risk > (group portage needed) and their resolution delays are a little too large... Thats tricky. There are several classes of RPATH checks that take place. The logic is as follows. ------------------------------------------------------------------------------- static void rpath_security_checks(elfobj *elf, char *item) { struct stat st; switch (*item) { case '/': break; case '.': warnf("Security problem with relative RPATH '%s' in %s", item, elf->filename); break; case '\0': warnf("Security problem NULL RPATH in %s", elf->filename); break; case '$': if (fstat(elf->fd, &st) != -1) if ((st.st_mode & S_ISUID) || (st.st_mode & S_ISGID)) warnf("Security problem with RPATH='%s' in %s with mode set of %o", item, elf->filename, st.st_mode & 07777); break; default: warnf("Maybe? sec problem with RPATH='%s' in %s", item, elf->filename); break; } } ------------------------------------------------------------------------------- Case 0 is the one you mention koon. But 1 & 2 '.' & '\0' are the two really bad ones that we must abort on.
Then we should not abort on the /var/tmp/portage case, which represents 95% of the rpath problem cases and that 95% of our users don't care about. This is breaking large parts of stable portage packages, lots of bugs are created but only a few are fixed, so this needs to be changed asap... I agree to break on the null cases which are evil, but certainly not on the /var/tmp/portage thing. I'll file a specific bug about this. Not sure who we should assign it to though.
See bug 117335 for followup on this off-topic discussion
media-video / vapier, could you have a look at comment #6 about absolute refs ?
Now if vapier can tell me why he blocked 0.104-r1 stable marking (bug #118073) we can solve this problem, i think?
Yes, "0.104-r1 should not be stable" needs some explanation.
The next ~arch portage revision will auto repair evil rpaths and not bail. Maintainers should still fix the packages they maintain as portage will only die with FEATURES=stricter (but that is a maintainer & QA problem) no longer security@ http://bugs.gentoo.org/show_bug.cgi?id=124962
> Now if vapier can tell me why he blocked 0.104-r1 stable marking (bug #118073) > we can solve this problem, i think? look at Bug 121871 i havent gotten around to fixing the PIC patch
No longer a security issue with current stable portage, re-assigning to maintainer.
0.104 works fine
0.104-r1 also merged successfully, shall it be marked as stable?
go to Bug 118073
