httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From KaiGai Kohei <>
Subject Re: [RFC] A new hook: invoke_handler and web-application security
Date Wed, 08 Apr 2009 08:43:47 GMT
Graham Dumpleton wrote:
> 2009/4/8 KaiGai Kohei <>:
>> Graham Dumpleton wrote:
>>> 2009/4/8 KaiGai Kohei <>:
>>>> KaiGai Kohei wrote:
>>>>> Graham Dumpleton wrote:
>>>>>> 2009/4/8 KaiGai Kohei <>:
>>>>>>> Graham Dumpleton wrote:
>>>>>>>> Explain first why using FASTCGI and suexec wouldn't be a
better option?
>>>>>>> Thease are limited to cgi applications, so we cannot apply such
>>>>>>> of restriction on the built-in script languages and references
>>>>>>> static documents (like *.html).
>>>>>> FASTCGI is not restricted to CGI applications. At least in the sense
>>>>>> that FASTCGI allows persistent processes rather than one off processes
>>>>>> like CGI. FASTCGI bindings are available for many different languages,
>>>>>> including scripting languages, so what 'built-in script languages'
>>>>>> you talking about? The suexec mechanism comes into play as it allows
>>>>>> FASTCGI processes to run as a different user than Apache process.
>>>>> Hmm... I'll try to search for more details of features of FastCGI.
>>>>> If you have a hint, could you tell for the questions currently I have?
>>>>> IIRC, the CGI version of PHP cannot handle applications which write
>>>>> out special HTTP headers, such as WWW-Authenticate: or Location:.
>>>>> Is it possible to handle correctly in FastCGI?
>>>>> I could not find FastCGI support for WebDav. Is it possible to control
>>>>> accesses on files using SELinux?
>>>> Hmm... It seems to me FastCGI has same limitation.
>>>> The online document introduces that an authenticator program can
>>>> be performed to handle authentication phase, but it may require
>>>> web applications to be modified.
>>>> If we don't hesitate to create a new process for each requests,
>>>> I have one another idea which does not require new hooks.
>>>> In the traditional client-server model, the server process forks
>>>> a child process to handle a request come from clients.
>>>> If we have such kind of MPM module, a security module can set
>>>> an individual privilege at the head of ap_run_handler hook.
>>>> Needless to say, it has performance tradeoff, but we assume users
>>>> don't give the highest priority on the performance.
>>> See experimental MPM from Apache 2.0.
>>> Didn't get carried through to later Apache versions.
>> If I can understand correctly, the perchild mpm assigns individual
>> userid per virtual host, so it means all the requests handled by
>> a certain virtual host shares same privilege set.
>> The purpose of my efforts is to set individual privileges for each
>> web users of the given request.
>> Thanks for your information, but it is not suitable for us...
> Rather than you say what changes you think need to be done at low
> level that you actually explain better at a high level what you are
> trying to do. It is really hard to respond to you when we have no real
> idea of the outcome you are trying to achieve.

Hmm... I've misunderstood that a discussion in abstracted-level does
not interest folks, because nobody replied to previous messages.
I also agree to rewind the discussion at the high level design what
I would like to resolve, needless to say.

> Specifically, what Apache modules are you trying to use that you
> specifically want requests to be handled as separate users. You
> mentioned 'built in scripting languages' before, but when I asked you
> what scripting languages, you didn't answer.

It contains something like mod_php, mod_perl and so on.
Indeed, FastCGI can support to execute scripts written in them.

In addition, I would like not to forget a path to access static
documents like *.html, *.pdf and others.
When a web system is set up to associate a security context with
http-authenticated users, we would like to apply consistent
access control rules independent from the way to access.
For example, if a privilege associated with web-user: kaigai is
not sufficient to access pdf files labeled as "classified",
it should not be allowed even if web-application (launched
by "kaigai") tries to access them, or even if the "kaigai" tries
to access with a url such as: http://..../path/to/file.pdf directly.

> As I have already pointed
> out, if you are trying to provide scripting language support for
> writing Python web applications then FASTCGI can be used, but then you
> have dismissed that based on authentication reasons but not really
> explaining what the problem is.

In my preference, I would like to run existing web-applications
without modifications as far as possible.
Some of them assumes *.php scripts are run on, thus
we often need to modify them to work on CGI version, for example.
It is not a preferable for us.

OSS Platform Development Division, NEC
KaiGai Kohei <>

View raw message