Boost logo

Boost-Build :

Subject: Re: [Boost-build] security: install rule links target in destination?
From: Roman Neuhauser (neuhauser_at_[hidden])
Date: 2009-12-23 22:09:44

# ghost_at_[hidden] / 2009-12-23 21:43:48 +0300:
> On Wednesday 23 December 2009 21:07:58 Roman Neuhauser wrote:

> > Running "bjam install" with insufficient privileges revealed interesting
> > behavior: it appears bjam runs ld on /usr/local/bin/maildirs:
> >
> > /usr/local/bin/maildirs
> > /usr/bin/ld: cannot open output file /usr/local/bin/maildirs: Permission denied
> >
> > "g++" -L"/usr/local/lib" -Wl,-rpath-link -Wl,"/usr/local/lib" -o "/usr/local/bin/maildirs" -Wl,--start-group "bin/gcc-4.2.1/release/maildirs.o" -Wl,-Bstatic -Wl,-Bdynamic -lboost_filesystem -Wl,--end-group -Wl,--strip-all
> >
> >
> > ...failed /usr/local/bin/maildirs...
> >
> > Security-wise, this is really undesirable. The install stage must not
> > do more than copy files.
> Roman,
> what security problems do you see? Are you worried about running the
> compiler as root user?

Somewhat. Call me paranoid but shit happens; see also ./configure
trojans ( The compiler
suite doesn't need to run as root to build this project and the program
will never run as root either, so why tease the devil?

> > Am I doing something wrong in the Jamroot, or is this "normal"?
> This is normal. For development, the 'maildirs' binary has rpath to the
> location of 'bfs' library (and other dependency libraries), so that
> running the binary just work. When installing, such hardcoding of
> rpaths is generally not desirable, so we relink the binary.

I'm doing this on FreeBSD. This operating system differs from Linux in
that /usr houses only the base operating system, packages go into /usr/local.
However, for whatever reason, /usr/local/lib is not searched by the runtime

The 'bfs' library is in fact /usr/local/; in bbv2
parlance it's a "prebuilt library". There are no libraries built as
part of the project. Whether the program runs from the build directory
or in the install path, it needs to have "-Wl,-rpath /usr/local/lib",
and as ldd shows, that's indeed the case:

roman_at_isis ~/codex/maildirs 1216:1 > ldd bin/gcc-4.2.1/release/maildirs
bin/gcc-4.2.1/release/maildirs: => /usr/local/lib/ (0x28097000) => /usr/lib/ (0x280aa000) => /lib/ (0x2819e000) => /lib/ (0x281b8000) => /lib/ (0x281c3000) => /usr/local/lib/ (0x282da000) => /lib/ (0x282de000)
roman_at_isis ~/codex/maildirs 1217:0 > ldd =maildirs
/usr/local/bin/maildirs: => /usr/local/lib/ (0x28097000) => /usr/lib/ (0x280aa000) => /lib/ (0x2819e000) => /lib/ (0x281b8000) => /lib/ (0x281c3000) => /usr/local/lib/ (0x282da000) => /lib/ (0x282de000)

Looks like the relink is gratuitous in the case of this project.

> If you set the 'hardcode-dll-paths' to 'false' then the relink should not
> happen.

I changed the rule to

exe maildirs
    : maildirs.cpp bfs
    : <include>/usr/local/include

but see no change in behavior. Can you please point out my mistake?

> But on the other hand, it will be inconvenient to run the binaries
> in the build tree.

That's only true if the program uses a dynamic library built as part of
the project (minor point).

More importantly: as I see it, this is trading minor maintainer
convenience for user safety. That seems to me like a bad deal for any
project that has at least one user.

> Some other build systems work in the same way, so presumably there's no better
> solution.

Well, popularity is rarely a proof of quality. ;)

Judging from the stuff I install the most popular build system in open
source software for unix-like systems is make. It has its warts but one
thing you can generally count on is that when "make all" is done, you
have the "real thing".

> Can you suggest something?

LD_LIBRARY_PATH is a bit less convenient than "it just runs", but IMO
still preferable. Keep in mind that it's less convenient only for the
maintainer(s), who are typically a miniscule minority of people who
build and install the software. Both maintainers and users mostly run
uninstalled software to excercise unit and/or regression tests. This
stuff is by definition automated, so LD_LIBRARY_PATH is a onetime
nuisance. For example:

check: pure
        @ $(LD_LIB_PATH)=".:$$$(LD_LIB_PATH)" \
          PURELIB=$(srcdir)/lib \
          PURE_INCLUDE=$(srcdir)/test \
          $(srcdir)/run-tests $(notdir $(tests))

Basically, I'd like to recreate the behavior of this Makefile fragment:

LDFLAGS=-Wl,-s -Wl,-L $(LCXXRT) -Wl,-rpath $(RCXXRT) -Wl,-L $(_BOOST)/lib

Roman Neuhauser

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at