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 07:06:43 GMT
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.

Graham

Mime
View raw message