Re: Retention of LD_LIBRARY_PATH

[Rich Felker <dalias@libc.org>]

On Sun, Aug 31, 2014 at 02:25:18PM +0400, Alexander Monakov wrote:
> (related to setproctitle discussion on IRC)
> 
> The dynamic loader in musl retains a pointer to LD_LIBRARY_PATH from the
> initial environment, which is exposed to the application via 'char **environ'.
> Changes to environ may cause subsequent calls to dlopen to use different
> search paths, but modifications via setenv and putenv do not have such effect.

"Any application that directly modifies the pointers to which the
environ variable points has undefined behavior."

http://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html

> dlopen(3) in Linux man pages mentions specifically that the value of
> LD_LIBRARY_PATH from program start up is used.  Glibc stores a duplicate of
> the initial value, and modifications to the environment do not affect search
> paths for dlopen.

The behavior is the same with musl in a program which does not invoke
UB: the string from startup is used, since it's not to be modified.

From a practical standpoint, I don't see any good way to support
duplication of the LD_LIBRARY_PATH string. It would need dynamic
allocation which can fail, or else a very large static buffer, or else
a small static buffer and enforcement of a max length on
LD_LIBRARY_PATH; in the case of using dynamic allocation it would need
to abort on failure. This is acceptable for the most part since the
dynamic linker already has to produce a fatal error when it cannot
allocate memory to load a library, but it's unfriendly behavior to the
common case of programs that don't use any shared libraries (except
libc), since they do not need allocation and thus are fully fail-safe
right now.

If the goal is just to support setproctitle, I would much rather keep
this as an explicit example of a practical reason you can't do it.
setproctitle is clobbering all sorts of memory in ways that seriously
invoke UB, and I do not want to even try to support it. If there's
really a demand for setproctitle, the kernel needs to be fixed to
support it correctly like BSD does, or, short of that, the program
needs to self-exec with a huge argv[0] so that it can overwrite
argv[0] without touching any other memory to implement setproctitle.

Rich