[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140831124152.GU12888@brightrain.aerifal.cx>
Date: Sun, 31 Aug 2014 08:41:52 -0400
From: Rich Felker <dalias@...c.org>
To: Alexander Monakov <amonakov@...ras.ru>
Cc: musl@...ts.openwall.com
Subject: Re: Retention of LD_LIBRARY_PATH
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
