Well, bummer. I think it would be a terrific improvement to
functionality if both of those things were implemented:
   1. AllowOverride negating (maybe we could do like AllowOverride all 
   2. mod_info/status & friends restricting (not allow being added in htaccess 
context, or give the option to remove that access?)
I just tested with some long AllowOverrideList configs and confirmed
going that route would allow me to (mostly) do what I'd like to do. I
still think it would be very nice to be able to load modules (or maybe
only allow access to module functionality?) under specific
Thanks again for the help.
On Sun, 2016-09-18 at 15:30 -0400, Eric Covener wrote:
> On Sun, Sep 18, 2016 at 3:25 PM, Adam 
> d> wrote:
> > 
> > Ah yes, the monkey wrench. So the reason why going that route isn't
> > an
> > option is because this is being done in a shared environment, with
> > .htaccess
> > enabled for users. In an environment like that, anyone can just
> > drop
> > SetHandler server-info into any .htaccess they want and get all of
> > that
> > (sometimes sensitive) info. Due to the nature of all this, it was
> > looking
> > like the only way to truly limit who could gain access to that info
> > would be
> > to only load the module itself under specific circumstances, which
> > is what
> > led me to where I'm at now.
> That's just not possible, modules can only be loaded at startup.
> > 
> > 
> > Is there a way I've not yet found that allows me to disable using
> > SetHandler
> > in an .htaccess context (while still allowing other things), or to
> > not allow
> > defining server-info there?
> You cannot really do it well.  You can block  all of FileInfo, or
> list
> what's overideable in AllowOverrideList but you can't use negation in
> that.
> There has been discussion in the past about moving some mods (like
> info and status) away from SetHandler configuration for this very
> reason but nothing was ever implemented.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org

Reply via email to