[Bug ld/31904] libdep.so plugin registers search path after default paths in bfd linker

[me at harmenstoppels dot nl]

https://sourceware.org/bugzilla/show_bug.cgi?id=31904

--- Comment #2 from Harmen Stoppels <me at harmenstoppels dot nl> ---
Hi Nick,

> The problem is that there is a libg.a in the standard library search paths 
> and this is being picked up instead of your local libg.a.

I realized that, changed the title of the bug report, but forget to post a
message. But thanks for checking anyways!

> Now I expect that you are going to say that the bfd linker ought to insert 
> search paths derived from the libdep plugin *before* other search paths.  

Indeed ;)

> But I would argue that this is a serious security risk.

Firstly, the plugin is not enabled by default, so users could know what they
sign up for.

Secondly, I also don't agree this is a risk, but rather how it should behave.
The plugin is supposed to make static linking similar to shared linking in that
the linker can resolve dependencies.

The correspondence should roughly be that __.LIBDEP's -L and -l are resp.
DT_RUNPATH and DT_NEEDED entries.

DT_RUNPATH by design specifies search paths local to the shared library. So
should these __.LIBDEP -L flags be. They should not affect global search path
state.

That is the real problem: object local search paths for dependencies are
transformed into global search paths in the bfd linker.

Finally, consider the motivating example in the documentation
https://sourceware.org/binutils/docs/ld/libdep-Plugin.html:

> For example, given a library libssl.a that depends on another library 
> libcrypto.a which may be found in /usr/local/lib, the ‘__.LIBDEP’ member of 
> libssl.a would contain
>   -L/usr/local/lib -lcrypto

It is incredibly likely that `libssl.a` is in a default/system search path like
/usr/lib. The wrong libssl.a will be linked and nobody will notice (unless it
causes a linking failure, which is unlikely). It's highly unexpected from a
user's perspective that the dependency is resolved to a path different from
that specified in the archive, don't you agree?

-- 
You are receiving this mail because:
You are on the CC list for the bug.