>>> Install ut2004-3369 into /var/tmp/portage/ut2004-3369/image/ category games-fps man: scanelf: rpath_security_checks(): Security problem with relative RPATH '.' in /var/tmp/portage/ut2004-3369/image//opt/ut2004/System/ut2004-bin QA Notice: the following files contain executable stacks Files with executable stacks will not work properly (or at all!) on some architectures/operating systems. A bug should be filed at http://bugs.gentoo.org/ to make sure the file is fixed. RWX --- --- opt/ut2004/System/ucc-bin RWX --- --- opt/ut2004/System/ut2004-bin >>> Completed installing ut2004-3369 into /var/tmp/portage/ut2004-3369/image/ As this is a binary package please work with upstream to get this fixed. http://www.gentoo.org/proj/en/hardened/gnu-stack.xml Portage 2.0.53 (default-linux/x86/2005.1, gcc-3.4.4, glibc-2.3.5-r3, 2.6.14-gentoo-r4 i686) ================================================================= System uname: 2.6.14-gentoo-r4 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz Gentoo Base System version 1.12.0_pre11 ccache version 2.4 [enabled] dev-lang/python: 2.4.2 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 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.16.1-r1 sys-devel/libtool: 1.5.20-r1 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium4 -pipe -mfpmath=sse -ffast-math -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/share/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/env.d/java/ /etc/gconf /etc/init.d /etc/java-config/vms/ /etc/splash /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium4 -pipe -mfpmath=sse -ffast-math -fomit-frame-pointer" DISTDIR="/usr/src/distfiles" FEATURES="autoaddcvs autoconfig ccache collision-protect cvs distlocks fixpackages sandbox sfperms sign strict stricter verify-rdepend" GENTOO_MIRRORS=" http://trumpetti.atm.tut.fi/gentoo http://lame.lut.fi/linux/gentoo " LANG="en_US.utf8" LC_ALL="en_US.utf8" LINGUAS="fi" MAKEOPTS="-j2 " PKGDIR="/home/pkg/" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/mnt/checkouts/overlays/betelgeuse /mnt/checkouts/overlays/axxo" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 aac acl acpi alsa apm arts audiofile avi bash-completion berkdb bitmap-fonts bluetooth browserplugin bzip2 bzlib cdb cddb cdparanoia cdr crypt cups dbus divx4linux dts dvd dvdr dvdread emboss esd expat fam ffmpeg firefox foomaticdb freetype gif glut gstreamer gtk2 hal idn java jpeg kde kdeenablefinal lcms libg++ libwww logitech-mouse mad makecheck mikmod mjpeg mmx mmx2 mng mp3 mpeg ncurses network nptl nptlonly nsplugin nvidia offensive ogg oggvorbis opengl pam pcre pdflib png qt quicktime readline real rtc ruby samba spell sse sse2 ssl subversion svg symlink tcpd theora tiff truetype truetype-fonts type1-fonts udev unicode usb userlocales vorbis win32codecs xine xml xml2 xv xvid zlib video_cards_nvidia linguas_fi userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LDFLAGS
I'll talk to upstream but I am very confident that this will be a WONTFIX on their end and CANTFIX on ours. This will be even more of an issue if you start going into the older Loki games, since there is no more upstream to talk with in existence.
*** Bug 114748 has been marked as a duplicate of this bug. ***
Ryan, can you look into this? I can file a bug on the icculus.org bugzilla if you would prefer.
I'm not sure where it's picking up the idea that ut2004 needs an executable stack (to my knowledge, we don't). Is there some way to pick out what part of the binary or the build process is causing this? Is there some way to just flag an existing ELF binary as "doesn't really need executable stack"? I'd like that heaps better than altering the existing build process, if possible. --ryan.
(In reply to comment #4) > I'm not sure where it's picking up the idea that ut2004 needs an executable > stack (to my knowledge, we don't). Is there some way to pick out what part of > the binary or the build process is causing this? > Please read the link I already gave you: http://www.gentoo.org/proj/en/hardened/gnu-stack.xml
if havent updated the docs or made a new release since i added the functionality yesterday, but i updated the `scanelf` util to look for object files which do not contain the .note.GNU-stack section ... such object files would cause the final binary to contain an executable stack i'll post back when ive done so
> Please read the link I already gave you: > http://www.gentoo.org/proj/en/hardened/gnu-stack.xml Whoops, I missed that, sorry. I'll read that now. --ryan.
ok, ive updated the gnu stack docs ... just grab the 0.1.5 tarball of pax-utils: http://dev.gentoo.org/~vapier/dist/pax-utils-0.1.5.tar.bz2 and then run `scanelf -qeR <path to compiled ut2004 source code>` it should help you locate the offending object files quickly
The new 3369-r1 version no longer fails. It still contains the relative RPATH, but it isn't an error.
(In reply to comment #9) > The new 3369-r1 version no longer fails. It still contains the relative RPATH, > but it isn't an error. QA Notice: the following files contain executable stacks Files with executable stacks will not work properly (or at all!) on some architectures/operating systems. A bug should be filed at http://bugs.gentoo.org/ to make sure the file is fixed. RWX --- --- opt/ut2004/System/ucc-bin RWX --- --- opt/ut2004/System/ut2004-bin !!! ERROR: games-fps/ut2004-3369-r1 failed. !!! Function dyn_install, Line 1102, Exitcode 0 !!! Aborting due to +x stack !!! If you need support, post the topmost build error, NOT this status message. Do you have pax-utils emerged?
Does portage not pull it in as a dependency? Anyway, I cannot fix this. It is a binary application. Ryan is aware of the issue. If he fixes it, great, if not, there's nothing that I can do about it.
(In reply to comment #11) > Does portage not pull it in as a dependency? 2.0.54 will have it. > Anyway, I cannot fix this. It is a binary application. Ryan is aware of the > issue. If he fixes it, great, if not, there's nothing that I can do about it. The approapriate resolution is upstream then. Reopening to change.
Being a binary application we need upstream to resolve this issue.
Ryan: I realized where the confusion came between myself and Petteri. I run amd64. He runs x86. On amd64, there are no problems. The problems only manifest on x86, which leads me to think that by default the compiler/linker on amd64 fixes this issue for you.
Should I file a bug with your bugzilla for this or is this still sufficient?
<wolf31o2-work> icculus: you see my latest responses on that executable stack bug? <icculus> wolf31o2-work: I did, and we might have a problem <wolf31o2-work> icculus: ok <icculus> wolf31o2-work: The 32-bit version uses Pixomatic <icculus> wolf31o2-work: which is not only a big pile of self-modifying assembly, it's (ahem) actually a win32 .obj file. <icculus> I don't know if it actually executes from the stack, but I can't flag it as safe. Unfortunately, it doesn't look like we can really fix this. I'm making comments to such in the ebuild.
no need to put comments in the ebuild just put RESTRICT=stricter ... that means we've analyzed the package and found it to be not fixable from our standpoint portage will still bitch about the situation, but it wont abort
