Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

scanelf: rpath_security_checks(): Security problem NULL DT_RUNPATH in
/var/tmp/portage/app-pda/libsyncml-0.4.6/image/usr/bin/syncml-http-client
scanelf: rpath_security_checks(): Security problem NULL DT_RUNPATH in
/var/tmp/portage/app-pda/libsyncml-0.4.6/image/usr/bin/syncml-http-server
scanelf: rpath_security_checks(): Security problem NULL DT_RUNPATH in
/var/tmp/portage/app-pda/libsyncml-0.4.6/image/usr/bin/syncml-obex-client

CCing KDE team as it might be caused by cmake 2.6.0

Okay this seems to be related to cmake 2.6.0 and this warning in particular:
CMake Warning (dev) at index/CMakeLists.txt:42 (add_library):
  Policy CMP0003 should be set before this line.  Add code such as

    if(COMMAND cmake_policy)
      cmake_policy(SET CMP0003 NEW)
    endif(COMMAND cmake_policy)

  as early as possible but after the most recent call to
  cmake_minimum_required or cmake_policy(VERSION).  This warning appears
  because target "sopranoindex" links to some libraries for which the linker
  must search:

I got this error out of soprano, and it also has the same NULL DT_RUNPATH. And
good enough it seems a quite big security risk (if it wasn't for scanelf).

This is not caused by cmake 2.6, but fixed by cmake 2.6.  To use they better
version, use cmake 2.6, and put 

if(COMMAND cmake_policy)
    cmake_policy(VERSION 2.6)
endif()

in your topmost CMakeLists.txt

For more information, see

cmake --help-policies

and look at 0003

I will be filing a bug to unmask cmake 2.6

(In reply to comment #2)
> Okay this seems to be related to cmake 2.6.0 and this warning in particular:
> CMake Warning (dev) at index/CMakeLists.txt:42 (add_library):
>   Policy CMP0003 should be set before this line.  Add code such as
> 
>     if(COMMAND cmake_policy)
>       cmake_policy(SET CMP0003 NEW)
>     endif(COMMAND cmake_policy)
> 
>   as early as possible but after the most recent call to
>   cmake_minimum_required or cmake_policy(VERSION).  This warning appears
>   because target "sopranoindex" links to some libraries for which the linker
>   must search:
> 
> I got this error out of soprano, and it also has the same NULL DT_RUNPATH. And
> good enough it seems a quite big security risk (if it wasn't for scanelf).
> 

The new cmake policy is better security-wise, but I don't know if will help
with the problem mentioned.  For more info, check

http://www.cmake.org/Wiki/CMake_RPATH_handling

From what I understand, you would want the 'Always Full RPATH' option?

As far as I can see with this individual applications will need to be patched
to use the correct policy. I will admit to not being an RPATH guru but it also
seems to me that the RPATH handling has been improved, it just needs to be set
up correctly by the application.

I am not sure if some of the CMake files will also need patching to find the
libraries they are linking to also. I do think it is important to bring CMake
2.6.0 out of package mask.

A simple fix, add -DCMAKE_NO_BUILTIN_CHRPATH:BOOL=ON to options.

http://markmail.org/message/7fexrgbrawejuhpl

CMake maintains a separate RPATH for binaries in the build tree and binaries in
the install tree.  The idea is to make it easy to run a binary that uses shared
libraries in its own build tree.  When the binary is installed (make install)
CMake sets the RPATH for the install tree copy of the binary to be whatever was
specified by the project (or removes the entry completely if nothing was
specified).

CMake has built-in chrpath functionality (which improves over the original tool
by supporting cross compiling).  It uses this to switch the RPATH in the
installed binary.  When the RPATH specified for the installed binary is longer
than the RPATH needed for running from the build tree, CMake reserves space in
the build-tree copy by appending ':' characters to fill up the space.  This is
what creates the empty RPATH entries.  However, these entries never get
installed.  The final binary always has the RPATH specified by the project for
the install tree copy.

What -DCMAKE_NO_BUILTIN_CHRPATH:BOOL=ON does is to tell CMake to create a new
binary for installation by linking again in order to set the new RPATH for the
install tree.  In this case there is no need to reserve space, so the
build-tree copy does not get the ':' characters appended.

Another fix is to tell CMake that we don't care about running from the build
tree so it should just link with the final install-tree RPATH right away:

  -DCMAKE_BUILD_WITH_INSTALL_RPATH:BOOL=ON

This will avoid the re-linking step and avoid creating empty RPATH entries in
any copy of the binary.

If someone can tell me how to reserve extra space in the RPATH string through a
standard linker interface without creating a bogus path, I'd love to use it
instead of appending ':' characters.

(In reply to comment #7)
> Another fix is to tell CMake that we don't care about running from the build
> tree so it should just link with the final install-tree RPATH right away:

USE="test" often runs things in the build tree, no? Maybe something to
consider.

I suggest to add -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=1 and
-DCMAKE_BUILD_WITH_INSTALL_RPATH=1 to cmake-utils.eclass as
cmake-2.6.1/CMakeLists.txt.

Created an attachment (id=162856) [details]
cmake-utils-rpath.patch

I finally got access to a friend's gentoo box and was able to reproduce this
problem.  It looks like the gentoo linker is using --enable-new-dtags by
default.  Using this flag on my debian machine I was able to reproduce the
problem too.  The bug is that CMake removes only the DT_RPATH entry and zeroes
its string.  The DT_RUNPATH entry is left intact but it refers to the same
string data which have now been zeroed so it becomes an empty string.

I've committed a fix to CMake HEAD in CVS.  We'll include the fix in the 2.6.2
release.

> 
> I've committed a fix to CMake HEAD in CVS.  We'll include the fix in the 2.6.2
> release.
> 

Awesome.  Thanks for working so hard on this.

(In reply to comment #11)
> I've committed a fix to CMake HEAD in CVS.  We'll include the fix in the 2.6.2
> release.
> 

Any ETA for this release? otherwise could you indicate the exact CVS diff so we
can patch 2.6.0 until 2.6.2 is out? Thanks.

Created an attachment (id=163847) [details]
Patch from upstream cmake fixing this bug.  Applies cleanly to 2.6.1.

Here is a patch I generated to backport the fix to 2.6.1.

I've just added cmake-2.6.1 to the tree which applies the patch kindly provided
by upstream, big thanks Brad!

Arches, please test and mark stable dev-util/cmake-2.6.1. 
Target keywords: "alpha amd64 arm hppa ia64 mips ppc ppc64 s390 sh sparc x86
~x86-fbsd"

Wait -- Did this ever affect any stable system?
As far as I understand, cmake 2.6* has been under p.mask until very recently.

in fact, it is still masked. Un-cc'ing arches.

Just to make sure: Our stable (pre 2.6.0) was not affected by this behaviour?

I am bringing cmake-2.6.1 out of package mask as all looks well now. Is there
any reason this bug is still open?

(In reply to comment #19)
> I am bringing cmake-2.6.1 out of package mask as all looks well now. Is there
> any reason this bug is still open?
> 
Yes, as rbu pointed out in comment #18, we need to know if cmake < 2.6 was
affected or not since it was stable. If no, we can close this bug. If yes,
we'll probably need to stable a fixed version. 

The code in question was introduced in CMake 2.6.0, so there is no problem for
2.4.x and below.

Thanks, closing then.