Graham Dumpleton wrote: > 2009/4/9 KaiGai Kohei <[email protected]>: >>>> 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 <[email protected]>
