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 LD_LIBRARY_PATH. 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... Regards, Yann.
