httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From KaiGai Kohei <kai...@ak.jp.nec.com>
Subject Re: [RFC] A new hook: invoke_handler and web-application security
Date Thu, 09 Apr 2009 08:18:37 GMT
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 is unclear for me whether it really has an advantage rather than
per-request creation design.
Please tell me, if I'm looking at something pointless.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

Mime
View raw message