Re: [Boost-build] security: install rule links target in destination?

Subject: Re: [Boost-build] security: install rule links target in destination?
From: Vladimir Prus (ghost_at_[hidden])
Date: 2009-12-23 13:43:48

On Wednesday 23 December 2009 21:07:58 Roman Neuhauser wrote:

> Hello,
> 
> learning Boost.Build, I have the following simple Jamroot:
> 
> project maildirs
>     : default-build release
> ;
> 
> install install
>     : maildirs
>     : <location>/usr/local/bin
> ;
> 
> exe maildirs
>     : maildirs.cpp bfs
>     : <include>/usr/local/include
> ;
> 
> lib bfs
>     :
>     : <name>boost_filesystem
>     : <search>/usr/local/lib
> ;
> 
> Running "bjam install" with insufficient privileges revealed interesting
> behavior: it appears bjam runs ld on /usr/local/bin/maildirs:
> 
> gcc.link /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 gcc.link /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?

> 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.

If you set the 'hardcode-dll-paths' to 'false' then the relink should not
happen. But on the other hand, it will be inconvenient to run the binaries
in the build tree.

Some other build systems work in the same way, so presumably there's no better
solution. Can you suggest something?

- Volodya