disabling directives in .htaccess files

2012-02-10 Thread Aaron Knister
Hi,

I'm using mod_perl in a shared hosting environment for some server-side
configuration bits. All dynamic content for the users runs through SuEXEC,
however this obviously doesn't help in the case of mod_perl so I would like
to prevent users from specifying any handlers or other potentially
undesirable mod_perl options/directives in their .htaccess files.

I was thinking of something along these lines:

A per-directory config directive called PerlHtaccessOverrides with possible
values of Handlers, Others, Env, Options, All and None. These names are
based what seemed to be perceived significant groupings of the MP_CMD_DIR_*
cmd's in modperl_cmds.c.

Each cmd function would then check its context to see if it's an htaccess
file, and would check against the list of allowed htaccess overrides for
that location and deny accordingly. I'd also need to modify the Code.pm
file that generates most of the handler cmd definitions.

I've something like this working right now, so I know it's possible but
it's not quite as I described here so I need to re-write it.

Any feedback would be appreciated-- I don't want to write a patch that's
not likely to be accepted upstream :)

Thanks!

-Aaron

-- 
Aaron Knister
Systems Administrator
Division of Information Technology
University of Maryland, Baltimore County
aar...@umbc.edu


Re: disabling directives in .htaccess files

2012-02-10 Thread Dave Hodgkinson

On 10 Feb 2012, at 11:46, Aaron Knister wrote:

> Hi,
> 
> I'm using mod_perl in a shared hosting environment for some server-side 
> configuration bits. All dynamic content for the users runs through SuEXEC, 
> however this obviously doesn't help in the case of mod_perl so I would like 
> to prevent users from specifying any handlers or other potentially 
> undesirable mod_perl options/directives in their .htaccess files.

Are the Apaches fronted by proxies?

In which case, I'd seriously consider everyone having their own Apaches with a 
limited
number of processes and an appropriately (automatically generated?) startup.pl 
for maximum
shared memory in those processes.

Obviously, that number can be tuned depending on the site, but you'd be 
surprised at how
few most sites need if the responses are quick.

See Stas Bekman's immortal tuning work.




Re: disabling directives in .htaccess files

2012-02-10 Thread Aaron Knister
Hi Dave,

Thanks for the feedback. Unfortunately the setup isn't fronted by apache 
proxies. Having an apache instance per site would, I think, be painful-- this 
is a personal web hosting setup for 80,000+ individual sites (think 
mod_userdir). 

Sent from my iPhone

On Feb 10, 2012, at 7:20 AM, Dave Hodgkinson  wrote:

> 
> On 10 Feb 2012, at 11:46, Aaron Knister wrote:
> 
>> Hi,
>> 
>> I'm using mod_perl in a shared hosting environment for some server-side 
>> configuration bits. All dynamic content for the users runs through SuEXEC, 
>> however this obviously doesn't help in the case of mod_perl so I would like 
>> to prevent users from specifying any handlers or other potentially 
>> undesirable mod_perl options/directives in their .htaccess files.
> 
> Are the Apaches fronted by proxies?
> 
> In which case, I'd seriously consider everyone having their own Apaches with 
> a limited
> number of processes and an appropriately (automatically generated?) 
> startup.pl for maximum
> shared memory in those processes.
> 
> Obviously, that number can be tuned depending on the site, but you'd be 
> surprised at how
> few most sites need if the responses are quick.
> 
> See Stas Bekman's immortal tuning work.
> 
> 



Re: disabling directives in .htaccess files

2012-02-10 Thread Torsten Förtsch
On Friday, 10 February 2012 06:46:01 Aaron Knister wrote:
> I was thinking of something along these lines:
> 
> A per-directory config directive called PerlHtaccessOverrides with possible
> values of Handlers, Others, Env, Options, All and None. These names are
> based what seemed to be perceived significant groupings of the MP_CMD_DIR_*
> cmd's in modperl_cmds.c.

Perhaps something along these lines:

  http://perl.apache.org/docs/2.0/user/config/config.html#C_Perl_Handler_

Torsten Förtsch

-- 
Need professional modperl support? Hire me! (http://foertsch.name)

Like fantasy? http://kabatinte.net



Re: disabling directives in .htaccess files

2012-02-10 Thread Aaron Knister
Hi Torsten,

I actually tried that. Problem is when I disable a given handler I can't use it 
at all, not even in the configs. I essentially want to be able to configure 
access handlers in the apache configs but disallow users from specifying ant 
handlers in their htaccess files. I can't turn off the overrides that allow 
that because it breaks other required features. IMHO the bigger issue here is 
the lack of fine grained override controls in httpd on htaccess files in 
general, but I digress. 

Sent from my iPhone

On Feb 10, 2012, at 9:03 AM, Torsten Förtsch  wrote:

> On Friday, 10 February 2012 06:46:01 Aaron Knister wrote:
>> I was thinking of something along these lines:
>> 
>> A per-directory config directive called PerlHtaccessOverrides with possible
>> values of Handlers, Others, Env, Options, All and None. These names are
>> based what seemed to be perceived significant groupings of the MP_CMD_DIR_*
>> cmd's in modperl_cmds.c.
> 
> Perhaps something along these lines:
> 
>  http://perl.apache.org/docs/2.0/user/config/config.html#C_Perl_Handler_
> 
> Torsten Förtsch
> 
> -- 
> Need professional modperl support? Hire me! (http://foertsch.name)
> 
> Like fantasy? http://kabatinte.net
> 


Re: disabling directives in .htaccess files

2012-02-10 Thread Dave Hodgkinson

On 10 Feb 2012, at 13:50, Aaron Knister wrote:

> Hi Dave,
> 
> Thanks for the feedback. Unfortunately the setup isn't fronted by apache 
> proxies. Having an apache instance per site would, I think, be painful-- this 
> is a personal web hosting setup for 80,000+ individual sites (think 
> mod_userdir). 

And al these sites could load their own perl? Painful.

And PLEASE front the sites with a reverse proxy: squid, varnish whatever. If
not, you're opening yourself up to all kinds of badness. Mod_perl is an *app*
server, not a web server.

Please read Stas' chapter on performance tuning!

Chapters 9 and 10:

http://modperlbook.org/html/part2.html

And the others.