detecting .htaccess in a per-dir directive handler (control mod_fcgid FcgidWrapper use in htaccess via per-server config)

[Jeff Trawick <tr...@gmail.com>]

mod_fcgid unfortunately allows the FcgidWrapper directive to be
overridden in htaccess when AllowOverride FileInfo is declared.  In
all likelihood some users need that (the feature was contributed and
added in mod_fcgid 2.1, it is especially handy to tweak PHP settings),
but definitely some admins do not want them to use it.

There's no obvious AllowOverride control for this directive, and
there's the legacy compatibility concern too.  Given this, the best
way to solve the problem AFAIK is to detect htaccess mode and consult
a per-server setting to see if the directive should be allowed.
BETTER SUGGESTIONS?

The best way to detect htaccess mode that I know of is to maintain a
flag in pre-config and post-config hooks which indicate whether we're
processing the main config; if we're not processing the main config
then assume we're processing htaccess.  BETTER SUGGESTIONS?

Re: detecting .htaccess in a per-dir directive handler (control mod_fcgid FcgidWrapper use in htaccess via per-server config)

[Graham Dumpleton <gr...@gmail.com>]

On 18 May 2010 05:13, Jeff Trawick <tr...@gmail.com> wrote:
> mod_fcgid unfortunately allows the FcgidWrapper directive to be
> overridden in htaccess when AllowOverride FileInfo is declared.  In
> all likelihood some users need that (the feature was contributed and
> added in mod_fcgid 2.1, it is especially handy to tweak PHP settings),
> but definitely some admins do not want them to use it.
>
> There's no obvious AllowOverride control for this directive, and
> there's the legacy compatibility concern too.  Given this, the best
> way to solve the problem AFAIK is to detect htaccess mode and consult
> a per-server setting to see if the directive should be allowed.
> BETTER SUGGESTIONS?
>
> The best way to detect htaccess mode that I know of is to maintain a
> flag in pre-config and post-config hooks which indicate whether we're
> processing the main config; if we're not processing the main config
> then assume we're processing htaccess.  BETTER SUGGESTIONS?

Could be wrong, but I was under the impression that cmd->config_file
is NULL when processing main Apache configuration file.

It was a long time ago, but the comment I wrote in mod_python in
respect of this was:

    } else if (cmd->config_file != NULL) {
        /* cmd->config_file is NULL when in main Apache
         * configuration file as the file is completely
         * read in before the directive is processed as
         * EXEC_ON_READ is not set in req_override field
         * of command_struct table entry. Thus know then
         * we are being used in a .htaccess file. */
        ...
    }

To be honest though, cant remember what I even meant by the latter
part of the comment.

Anyway, the issue you are dealing with is an issue am having to deal
with at present in mod_wsgi. That is, don't want to always allow stuff
if AuthConfig or FileInfo overridden as allowing people to hook Python
script code in .htaccess can be a security issue in itself. I don't
though want it to be allowed or disallowed across whole Apache, but
still be able to say allowed for certain directory contexts if need be
where users are trusted.

I was looking at a new directive for mod_wsgi which could only be
specified in main Apache configuration, but still within Directory
context, which would allow one to say whether or not can do stuff in
.htaccess. Problem as I saw it, although haven't looked further, is
that to allow it to be done selectively, can only enforce it at time
of handling request and not at time of reading in configuration from
.htaccess.

Graham

Re: detecting .htaccess in a per-dir directive handler (control mod_fcgid FcgidWrapper use in htaccess via per-server config)

["William A. Rowe Jr." <wr...@rowe-clan.net>]

On 5/18/2010 1:10 AM, William A. Rowe Jr. wrote:
> On 5/18/2010 12:17 AM, Nick Kew wrote:
>>
>> On 17 May 2010, at 20:13, Jeff Trawick wrote:
>>
>>> BETTER SUGGESTIONS?
>>
>> I never quite understood our AllowOverride being set in stone,
>> and many times I've felt that using any of the existing ones for a new
>> function was a grotty hack.  OTOH it doesn't really scale to adding
>> new options ad lib.
>>
>> Reading this and Graham's followup, I wonder if we should introduce
>> a single new option, something like "auto", for the semantics of
>> what you're doing?  Exact behaviour would be to turn on/off the
>> check Graham suggests or similar, on top of some other option.
> 
> What about requiring AllowOverride All for this case?

Another specific option would be some extensible keyword registration al la
Mutex.

Re: detecting .htaccess in a per-dir directive handler (control mod_fcgid FcgidWrapper use in htaccess via per-server config)

["William A. Rowe Jr." <wr...@rowe-clan.net>]

On 5/18/2010 12:17 AM, Nick Kew wrote:
> 
> On 17 May 2010, at 20:13, Jeff Trawick wrote:
> 
>> BETTER SUGGESTIONS?
> 
> I never quite understood our AllowOverride being set in stone,
> and many times I've felt that using any of the existing ones for a new
> function was a grotty hack.  OTOH it doesn't really scale to adding
> new options ad lib.
> 
> Reading this and Graham's followup, I wonder if we should introduce
> a single new option, something like "auto", for the semantics of
> what you're doing?  Exact behaviour would be to turn on/off the
> check Graham suggests or similar, on top of some other option.

What about requiring AllowOverride All for this case?

Re: detecting .htaccess in a per-dir directive handler (control mod_fcgid FcgidWrapper use in htaccess via per-server config)

[Nick Kew <ni...@webthing.com>]

On 17 May 2010, at 20:13, Jeff Trawick wrote:

> BETTER SUGGESTIONS?

I never quite understood our AllowOverride being set in stone,
and many times I've felt that using any of the existing ones for a new
function was a grotty hack.  OTOH it doesn't really scale to adding
new options ad lib.

Reading this and Graham's followup, I wonder if we should introduce
a single new option, something like "auto", for the semantics of
what you're doing?  Exact behaviour would be to turn on/off the
check Graham suggests or similar, on top of some other option.

-- 
Nick Kew