MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0010334CMakeCTestpublic2010-02-25 23:012016-06-10 14:31
ReporterDerek Bruening 
Assigned ToBill Hoffman 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformOSOS Version
Product VersionCMake-2-8 
Target VersionFixed in Version 
Summary0010334: Linux release binaries missing GNU_STACK which results in +x mmaps under ctest
DescriptionI downloaded the 2.8 cmake linux binary package
(http://www.cmake.org/files/v2.8/cmake-2.8.0-Linux-i386.tar.gz [^]) and the
ctest binary does not have a GNU_STACK section. This causes my kernel to
set the READ_IMPLIES_EXEC personality flag for ctest and all its children,
which means that all mmaps have +x set -- which causes one of my tests to
fail, in addition to being a security faux pas if ctest doesn't really need
+x memory.

Are you deliberately building these without a GNU_STACK section? Normally
gcc should add one by default, unless you have assembler sources.
You can tell the linker to make any existing GNU_STACK section -x, which
maybe will add a section if you don't have one? (I know /usr/bin/execstack
refuses to add one), with:

  -Wl,-z,noexecstack

There's some basic info here:
http://www.gentoo.org/proj/en/hardened/gnu-stack.xml [^]

I'm not 100% sure there's no downside to adding the section if you want to
run on really old systems but certainly on any relatively modern system binaries should have a GNU_STACK section.

Looks like the 2.6.4 binaries on the cmake website have the same issue.
The version distributed by Redhat for Fedora does have GNU_STACK so I never
noticed it before.

Note that as a workaround I simply built 2.8 locally from sources using my
distro's toolchain and the resulting binary is fine.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2010-02-25 23:01Derek BrueningNew Issue
2010-02-26 10:06Bill HoffmanStatusnew => assigned
2010-02-26 10:06Bill HoffmanAssigned To => Brad King
2010-02-26 11:42Brad KingAssigned ToBrad King => Bill Hoffman
2010-02-26 11:43Brad KingNote Added: 0019645
2010-02-26 12:06Bill HoffmanNote Added: 0019646
2010-02-26 12:26Derek BrueningNote Added: 0019647
2010-03-10 11:08Marcus D. HanwellNote Added: 0019807
2010-03-10 11:09Marcus D. HanwellNote Edited: 0019807
2016-06-10 14:27Kitware RobotNote Added: 0041657
2016-06-10 14:27Kitware RobotStatusassigned => resolved
2016-06-10 14:27Kitware RobotResolutionopen => moved
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0019645)
Brad King   
2010-02-26 11:43   
Bill, this bug is due to the toolchain you use to build the release. It has nothing to do with the content of the source tree.
(0019646)
Bill Hoffman   
2010-02-26 12:06   
We are building with an compiler linux distro so that it will work on as many machines as possible. However, these options seem to work on that compiler: -Wl,-z,noexecstack. How can you tell if an executable has this problem or not?
(0019647)
Derek Bruening   
2010-02-26 12:26   
if you have the execstack program you can run it with -q and it should show a - instead of ?, like so:

> execstack -q /extsw/pkgs/cmake/cmake-2.8.0-Linux-i386/bin/ctest
? /extsw/pkgs/cmake/cmake-2.8.0-Linux-i386/bin/ctest
> execstack -q /usr/bin/ctest
- /usr/bin/ctest

or you can look directly for the GNU_STACK section (and while at it verify the perms are +rw and not +rwx):
> readelf -l /extsw/pkgs/cmake/cmake-2.8.0-Linux-i386/bin/ctest | grep -A 1 STACK
> readelf -l /usr/bin/ctest | grep -A 1 STACK
  GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000 RW 8
(0019807)
Marcus D. Hanwell   
2010-03-10 11:08   
(edited on: 2010-03-10 11:09)
I suspect what may be happening is that we are building CMake on a really old system, and that is not aware of that section. This is intentional as you said, and may well require a compiler/linker upgrade to remedy. Then you we want the binary to work on ancient Linux systems...

There are the flags you can pass to modern GCC to build compatible binaries too, but I am not sure that the generic binaries we supply for Linux can necessarily be expected to contain new compiler/linker sections. I am exploring the possibility of using the opensuse build service to provide more targeted binaries - this might satisfy your needs.
(0041657)
Kitware Robot   
2016-06-10 14:27   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.