On Mon, Apr 9, 2018 at 10:07 AM, Joe Orton <jor...@redhat.com> wrote:
> On Thu, Apr 05, 2018 at 01:38:05PM +0200, Yann Ylavic wrote:
>> On Wed, Oct 11, 2017 at 4:48 PM,  <jor...@apache.org> wrote:
>> > Author: jorton
>> > Date: Wed Oct 11 14:48:55 2017
>> > New Revision: 1811831
>> >
>> > URL: http://svn.apache.org/viewvc?rev=1811831&view=rev
>> > Log:
>> > * server/util_script.c (ap_add_common_vars): Allow mod_env to override
>> >   all system path environment variables, not just PATH.  (The
>> >   behaviour for PATH alone was changed in r965679 for PR 43906.)
>> Since SetEnv* are usable from htaccess, don't we open a risky door here?
> If we allow control over PATH (which we do already) I am struggling to
> imagine how it would be worse to allow control of anything other env
> var.

LD_LIBRARY_PATH (and alike) look even more "fun" to play with, possibly.
Whilst applications may not need/use PATH, they can't do much about

PR 43906 states that one can already overwrite LD_LIBRARY_PATH, it's
not the case anymore today I think (w/o this commit).

> Can you think of a scenario where it would be a problem?

Custom .so in /path/to/my/htaccess-ed/htdocs for instance which would
be loaded underneath the app (with the same rights).
Although I agree that PATH may already be an issue, so it all depends
on the "trust" given to htaccess files I suppose...
How about a directive to control that? yes it sucks, but...


Reply via email to