# How to set LD_LIBRARY_PATH?



## edulsa (Feb 13, 2022)

Dear

I have a linux native software (the source code is not available, so, compiling it is not a option) that requires:
1) the path must be specified: no problem because I just added the complete path in my .login file. I tested a serial job and works fine.
2) I must specify where openmpi libs are. In the FAQ/TUTORIAL of this software, the solution is simple: export (or setenv) LD_LIBRARY_PATH pathtoopenmpilibs:$LD_LIBRARY_PATH

Here is my problem: there is no LD_LIBRARY_PATH defined and I cannot (and, I think, I must not) set it. 

My box is:
FreeBSD matata 13.0-RELEASE-p7 FreeBSD 13.0-RELEASE-p7 #15 e5733e6d9: Mon Feb  7 18:40:56 -03 2022     root@matata:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64


Please, could you give a hint about this problem?

Thank you in advance
Yours

Eduardo


----------



## AdrianAli (Feb 16, 2022)

ldconfig(8)
					






					www.freebsd.org


----------



## AdrianAli (Feb 16, 2022)

AdrianAli said:


> ldconfig(8)
> 
> 
> 
> ...


"
*SECURITY*
     Special care must be taken    when loading shared libraries into the address
     space of set-user-Id programs.  Whenever such a program is    run by any
     user except the owner of the program, the dynamic linker will only    load
     shared libraries from the hints file.  In particular, the LD_LIBRARY_PATH
     is    not used to search for libraries.  Thus, the role of *ldconfig* is dual.
     In    addition to building a set of hints for    quick lookup, it also serves
     to    specify    the trusted collection of directories from which shared    ob-
     jects can be safely loaded"


----------



## edulsa (Feb 16, 2022)

Dear Adrian

Thank you for your answer. I had read something in this reasoning and found that it explains that LD_LIBRARY_PATH is not a system variable anymore. But, even in native linux, this software claims that LD_LIBRARY_PATH must be set. Thus, I think the only solution is install a virtual machine (I have experienced VirtualBox but I think there are better solutions) and run it inside.

My best regards

Yours

Eduardo


----------



## _martin (Feb 18, 2022)

For the sake of setting the env variable: it's OK if that env variable doesn't exist. You can set it `LD_LIBRARY_PATH="/my/lib:$LD_LIBRARY_PATH"` even if environment variable is not set. It's a way of expanding the variable without losing its original content (be it empty).

Sane way of doing this would be creating wrapper script, e.g. `startme.sh` where you'd define this environment variable and then start the binary in question.

As mentioned above LD_LIBRARY_PATH is ignored when setuid binary is executed (for obvious reasons: you'd compromise security otherwise). If your program doesn't use setuid/setgid you are safe to use them though. 

But as you are on FreeBSD running native Linux binary you opened another can of worms -- Linux ABI support. It may or may not work, depending how new that binary is and what it does.


----------



## SirDice (Feb 18, 2022)

_martin said:


> it's OK if that env variable doesn't exist. You can set it `LD_LIBRARY_PATH="/my/lib:$LD_LIBRARY_PATH"` even if environment variable is not set.


This is actually really bad practice. Because LD_LIBRARY_PATH is empty you end up with a library path set to `/my/lib:`. Note the colon on the end, that adds an _empty_ path to it. Which then causes the current working directory to be searched for the library. Which in turn could lead to severe security implications. 






						Empty Entry in LD_LIBRARY_PATH May Lead to Security Issues
					

When I want to build glibc using the provided configure script (./configure --prefix=xxx), I saw the following error message:




					jdhao.github.io


----------



## _martin (Feb 18, 2022)

Note FreeBSD's ld.so doesn't behave this way.

While all this gets ignored on setuid binaries and I would not say "severe security implications" I do agree that better sanitation is a good idea to avoid this corner case.


----------

