Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4C9C0543.5020606@rowe-clan.net>
Date: Thu, 23 Sep 2010 20:56:19 -0500
From: "William A. Rowe Jr." <wrowe@rowe-clan.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
 rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: svn commit: r1000593 - in /httpd/httpd/trunk: CHANGES
 server/util_script.c
References: <20100923195015.5555A23888FD@eris.apache.org>
	<4C9BB23B.6080302@rowe-clan.net>
	<AANLkTi=crhOXgMJemURP-zjyqDL+M9GYa7w06BFrOUsa@mail.gmail.com>
	<4C9BD70E.8070309@rowe-clan.net>
 <AANLkTik5oYYvrbN8OPve9xWsr1kfAMVaVuPUv8t5xpo6@mail.gmail.com>
In-Reply-To: <AANLkTik5oYYvrbN8OPve9xWsr1kfAMVaVuPUv8t5xpo6@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 9/23/2010 6:58 PM, Jeff Trawick wrote:
> 
> These two are somewhat different in practice.
> 
> When the path to the binary is omitted on the invocation/load, the shell/loader/whatever finds
> 
> * executables only because of the PATH envvar

Correct

> * shared libraries usually via the system search path or in the executable/other-library's
> rpath

Typically, yes

> PATH always, LD_LIBRARY_PATH in exceptional situations

And always permitted at the shell prior to execution.  But once httpd has started,
dropping LD_LIBRARY_PATH deprives the kernel of resolving such libraries, due to
our arbitrary choice to propagate PATH, but not propagate LD_LIBRARY_PATH... leading
potentially to broken process invocations.  Does this make sense?

E.g. the choice to propagate PATH, but not LD_LIBRARY_PATH, seems foolish.  For those
who wish to argue the 'unsafety' of relocatable/dynamic path resolutions, is there
really any difference between propagating PATH but not LD_LIBRARY_PATH?