Add LD_LIBRARY_PATH type feature

[catenacyber]

Use of environment variable MANTICORE_LD_PATH
instead of LD_LIBRARY_PATH which is protected on MacOS

Fixes #93

---

This change is 

[catenacyber]

Better than #861 for handling interpreter error

[disconnect3d]

Please use open instead of file as the latter has been removed from Python 3 (which we will be compatible with soon).

[disconnect3d]

Use os.path.join to concatenate paths

[disconnect3d]

Also use a variable for the interpreter path.

[catenacyber]

Thanks @disconnect3d
Here come the changes

[yan]

Thanks again @catenacyber. I am thinking of what the best way to incorporate changes from this. I have a few concerns:

1. We don't use environment variables to pass other options to Manticore; this would be slightly bucking the trend.
2. In this case, MANTICORE_LD_PATH only controls the ELF interpreter loading path, not ld path in general. We can extend it to cover lib load path as well, that'd just require setting LD_LIBRARY_PATH.

[catenacyber]

We don't use environment variables to pass other options to Manticore; this would be slightly bucking the trend.

Ok, so I need to convert MANTICORE_LD_PATH environment variable to argument ld_path.
Or is there another way ? such as config file...

We can extend it to cover lib load path as well, that'd just require setting LD_LIBRARY_PATH

@yan I am not sure what you mean.
On MacOS, LD_LIBRARY_PATH is protected by so-called system integrity protection : you cannot set it.

[yan]

On MacOS, LD_LIBRARY_PATH is protected by so-called system integrity protection : you cannot set it.

What I meant was setting MANTICORE_LD_PATH won't actually affect the dynamic linker, so it's a misnomer. Further, macOS is not currently supported, we only support Linux guests.

What I meant above is, currently MANTICORE_LD_PATH only controls the ELF interpreter path; we should either name it as such (although I still believe a command line argument is potentially more appropriate), or forward along the library path to the emulated binary so that works as expected. Does that make sense?

[catenacyber]

Further, macOS is not currently supported, we only support Linux guests.

The point of this pull request is to progress towards macOS support

either name it as such
or forward along the library path to the emulated binary so that works as expected

The latter looks the best option to me.
What do you think ?

[yan]

@catenacyber The latter choice sounds reasonable to me as well. So this would include passing LD_LIBRARY_PATH=/... as an extra env variable on the command line and code in Linux to honor it for loading the interpreter.

[catenacyber]

thanks @yan you were faster than me

But there is a typo with one variable name interpreter_path_filename