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 so that it can overwrite argv 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.