httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Dumpleton <graham.dumple...@gmail.com>
Subject Re: [RFC] A new hook: invoke_handler and web-application security
Date Thu, 09 Apr 2009 11:00:52 GMT
2009/4/9 KaiGai Kohei <kaigai@ak.jp.nec.com>:
> Graham Dumpleton wrote:
>> 2009/4/9 KaiGai Kohei <kaigai@ak.jp.nec.com>:
>>>>> The reason why I would like to set privilege prior to the invocation
>>>>> of contents handler is to apply consistent access controls independent
>>>>> from what kind of script languages are used.
>>>> I understand that, but you seem to be focused on the idea of using
>>>> threads within a process and thus require SELinux security contexts,
>>>> with its limitations. If distinct processes are used, and they need
>>>> not be created for just a single request but held around while ever
>>>> their is activity related to that user, then you do not need SELinux
>>>> and so it is portable across more platforms. SELinux security contexts
>>>> would only be relevant to a process oriented solution if for some
>>>> reason you wanted to set greater constraints than what a user would
>>>> normally have imposed on them for a normal process run as that user.
>>> Yes, the thread level privilege is a characteristic in SELinux,
>>> thus it may prevent to port the feture to other platforms.
>>> At least, I don't have any preference between them to implement
>>> the security focused mpm. I can agree the mpm should create
>>> a process rather than a thread.
>>>
>>> However, I don't think it is reasonably possible a process to handle
>>> multiple requests, because authentication header is come for each
>>> times, so we cannot assume the second request should be handled with
>>> same privilege of the first one.
>>
>> I am not talking about successive requests over a keepalive socket,
>> but totally distinct requests, where distinct decision is made as
>> whether those requests should be passed through to the appropriate
>> user process.
>>
>> You really need to look at how perchild is implemented.
>
> Now I'm looking at the perchild implementation...
> Since I could not find it at the 2.2.x tree, I refer the 2.0.x tree.
> Is it correct for what you intend?
>
> From the quick overview, if I can understand correctly, it seems to me
> the perchild uses longjmp() to rewind the steps when an unexpected process
> receives a request for other virtual host. It makes decision at the
> post_read_request hook after the ap_update_vhost_from_headers(), but
> we need to do same thing at more deep stage (fixups?).

It has been a very long time since I looked at the code that
implements it. Either way, the intent in pointing it out was more the
architecture it uses rather than exactly how it is implemented.

> It is unclear for me whether it really has an advantage rather than
> per-request creation design.

For per request you mean a new process, then it should as far as
performance is concerned as the cost of a CGI like model of a new
process per request is significantly higher than using a persistent
process. This is one of the reasons FASTCGI came about in the first
place.

> Please tell me, if I'm looking at something pointless.

Only you would know that. But then, I could be pointing you at the
wrong MPM. There is from memory another by another name developed
outside of ASF which intends to do the same think. The way it is
implemented is probably going to be different and may be the one I am
actually thinking of. I can't remember the name of it right now.

Graham

Mime
View raw message