Retention of LD_LIBRARY_PATH

Retention of LD_LIBRARY_PATH

[Alexander Monakov]

(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.

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.

Alexander

Re: Retention of LD_LIBRARY_PATH

[Rich Felker]

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

Re: Retention of LD_LIBRARY_PATH

[Alexander Monakov]

On Sun, 31 Aug 2014, Rich Felker wrote:

> On Sun, Aug 31, 2014 at 02:25:18PM +0400, Alexander Monakov wrote:
> > 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."

This doesn't seem to cover pointed-to character data (which is 'char' rather
than 'const char') without modifying pointers.  Apologies for the sloppy
wording in my previous email: 'changes to environ' should have been 'changes
to LD_LIBRARY_PATH string value (but not location) via environ'.

So a conforming application can still notice a difference.  I don't feel it's
a big problem (non-const char **environ is very iffy to me), but I thought
pointing out this discrepancy wouldn't hurt.

Thanks for your explanations.

Alexander