Bugzilla Bug 117116

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