libc.so.6 in project directory causes major problems

[m4b]

rustc --version
rustc 1.19.0-nightly (fe7227f6c 2017-06-16)
cargo --version
cargo 0.20.0-nightly (bbfe9b3a9 2017-06-05)

Steps to repro:

1. cp a libc.so.6 to your project directory
2. run cargo test or cargo build

This might require an older libc.so.6, or something; looks like something is trying dlopen the version in my directory (also, why?), and the ABI is bad for whatever reason (just guessing).

m4b@efrit ::  [ ~/git/panopticon ] cp libc.so.6 ~/projects/scroll
m4b@efrit ::  [ ~/git/panopticon ] cd
m4b@efrit ::  [ ~ ] cd projects/scroll
m4b@efrit ::  [ ~/projects/scroll ] cargo test
   Compiling scroll v0.6.0 (file:///home/m4b/projects/scroll)
rustc: error while loading shared libraries: __vdso_time: invalid mode for dlopen(): Invalid argument
error: Could not compile `scroll`.
Build failed, waiting for other jobs to finish...
rustc: error while loading shared libraries: __vdso_time: invalid mode for dlopen(): Invalid argument
error: Could not compile `scroll`.

To learn more, run the command again with --verbose.

Original issue: das-labor/panopticon#304

[metux]

Why does the compile dlopen() anything from the source tree ?
And why does anything dlopen() libc ?

[m4b]

I had similar questions 😆

I wonder if I could ship a libc in a crates.io crate with a rewritten stub to the function it's trying to open to do random stuff on some users computer.

[sfackler]

Do you have . in your LD_LIBRARY_PATH?

[sfackler]

It's not clear to me why the assumption is that this is coming from a dlopen call. Why couldn't it be ld.so? You can try setting LD_DEBUG=all to have the dynamic linker print out info about what it's doing.

[m4b]

No I do not have "." in my LD_LIBRARY.

To make this even easier, please copy your libc.so.6 to some new cargo project, open this new libc in your favorite hex editor, zero out the elf header, run cargo clean followed by cargo build and it will report that libc.so.6 has an invalid header...

[m4b]

I believe in this case it was assumed that dlopen was called because in the original report dlopen is explicitly mentioned as having a bad argument by rustc.

Of course it may be some side effect, etc. But on two separate machines I can repro this fairly worrisome issue (e.g. Local libc used without messing with LD env variables), which suggests that dlopen is used

[sfackler]

What does the output of cargo clean && env LD_DEBUG=libs cargo build say?

[m4b]

Ah I'm pretty sure this is caused by rustc using RPATH in dynamic array.

Also I think this might be a security vulnerability

EDIT:

Actually not sure. Except that it's a problem

[sfackler]

I do not see this behavior with a stock x86_64-unknown-linux-gnu 1.18 release, for reference.

        55:	find library=libc.so.6 [0]; searching
        55:	 search path=/usr/local/bin/../lib		(RPATH from file rustc)
        55:	  trying file=/usr/local/bin/../lib/libc.so.6
        55:	 search path=/tmp/foo/target/debug/deps/tls/x86_64:/tmp/foo/target/debug/deps/tls:/tmp/foo/target/debug/deps/x86_64:/tmp/foo/target/debug/deps		(LD_LIBRARY_PATH)
        55:	  trying file=/tmp/foo/target/debug/deps/tls/x86_64/libc.so.6
        55:	  trying file=/tmp/foo/target/debug/deps/tls/libc.so.6
        55:	  trying file=/tmp/foo/target/debug/deps/x86_64/libc.so.6
        55:	  trying file=/tmp/foo/target/debug/deps/libc.so.6
        55:	 search cache=/etc/ld.so.cache
        55:	  trying file=/lib64/libc.so.6

[m4b]

Something is setting LD path and it is not me. I believe it is cargo. Running strings on cargo shows that LD_LIB env variable is in the binary, and briefly grepping through source shows that it does collect a set of env variables, and LD_LIB is amongst them, which is even more worrisome.

Unfortunately not in front of a computer at the moment, so can't paste output but someone sets LD variable to the rustup nightly toolchain (amongst other things)

@sfackler are you not able to repro this ?

[m4b]

What about nightly cargo ?

[jmesmon]

% rustc -V
rustc 1.20.0-nightly (9475ae477 2017-07-11)
% cargo -V
cargo 0.21.0-nightly (eb6cf012a 2017-07-02)
% rustup -V
rustup 1.5.0
% env | grep LD_
[no output]
% cp /usr/lib/libSegFault.so libc.so.6
% cargo clean && env LD_DEBUG=libs cargo build
[...]
rustc: relocation error: libc.so.6: symbol getenv, version GLIBC_2.2.5 not defined in file libc.so.6 with link time reference
error: Could not compile `byteorder`.
[...]

And some output filtered to libc.so mentions:

      8694:	find library=libc.so.6 [0]; searching
      8694:	  trying file=/home/cody/g/vblock/target/debug/deps/libc.so.6
      8694:	  trying file=tls/x86_64/libc.so.6
      8694:	  trying file=tls/libc.so.6
      8694:	  trying file=x86_64/libc.so.6
      8694:	  trying file=libc.so.6

So it looks reproducible at least with rustup on nightly.

[m4b]

@sfackler could you paste entire output of LD_DEBUG=libs with and without libc.so.6 in project root directory ?

[m4b]

@jmesmon thank you, I was starting to think I was losing my mind ;)

I'm sure it's a nightly issue now (cannot repro on stable) and that someone (cargo I'm looking at you since the variable mysteriously appears after control is transferred to the one in rustup directory) is setting the env variable

[sfackler]

Ok yeah it does look like nightly cargo is messing this up:

      1325:	find library=libc.so.6 [0]; searching
      1325:	 search path=/tmp/foo/target/debug/deps:tls/x86_64:tls:x86_64::/root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib		(LD_LIBRARY_PATH)
      1325:	  trying file=/tmp/foo/target/debug/deps/libc.so.6
      1325:	  trying file=tls/x86_64/libc.so.6
      1325:	  trying file=tls/libc.so.6
      1325:	  trying file=x86_64/libc.so.6
      1325:	  trying file=libc.so.6
rustc: error while loading shared libraries: libc.so.6: file too short

@alexcrichton

[alexcrichton]

Sorry I don't really understand anything here, not sure how much help I'll be

[sfackler]

@alexcrichton the root of the issue is that cargo's started producing a weird LD_LIBRARY_PATH:

/tmp/foo/target/debug/deps:tls/x86_64:tls:x86_64::/root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib

This in particular includes `` (i.e. the current directory), as well as tls, `x86_64`, and `tls/x86_64`.

[sfackler]

In contrast, stable Cargo produces this LD_LIBRARY_PATH:

/tmp/foo/target/debug/deps/tls/x86_64:/tmp/foo/target/debug/deps/tls:/tmp/foo/target/debug/deps/x86_64:/tmp/foo/target/debug/deps

The fact that those tls and x86_64 directories are involved at all is weird and probably a bug, but the specific bug here is the non-absolute paths.

[m4b]

I believe the tls and x86_64 prefixes suffixes can be ignored; I think it's the dynamic linker appending them, as I see the same issue when compiling and running a C program and passing LD_LIBRARY_PATH=merp

[sfackler]

Oh, weird!

[sfackler]

This is also present on beta

[brson]

@Mark-Simulacrum can you bisect cargo prs?

[mbrubeck]

I suspect #4006, which added lines like this:

 search_path.push(self.host_dylib_path.iter().collect());

where search_path is a Vec<PathBuf> and self.host_dylib_path is an Option<PathBuf>. If self.host_dylib_path is set to None then this will push an empty path into the search path.

[est31]

I've "bisected" the change to #41978 , which did this update of cargo, which seems to confirm @mbrubeck 's suspicion.

[est31]

Note that when running without rustup, I can't reproduce the bug.

[mbrubeck]

Submitted PR rust-lang/cargo#4278.

[brson]

Should be fixed on current beta. Can anyone confirm?

[m4b]

👍

Fixed for me! Great work!