On Tue, Nov 26, 2002 at 08:18:06PM -0500, Johannes Erdfelt wrote: > > Perhaps perchild can be improved further to have a set of listener > > processes/threads, under the generic apache user id or another secured id, > > which accepts connections but does not process them. These threads then > > pass the connections on to the correct user-owned child id via the named > > sockets, allowing these child users to have no listening sockets at all > > (except the unix domain socket). > > It would need to be a process. Mixing uid's among threads is not > portable.
I meant 1 or more processes with 1 or more threads each. Has any work been done on testing whether it's best to have 100 processes listening or 10 processes with 10 threads each all listening, or 10 processes with 10 threads each with one listener thread per process, etc. etc.? I was vague because I don't know best practice. > Switching to a model like is possible, but I'm willing to be that > passing fd's is not cheap and would just create overhead. > Do you want to do this for security reasons? Yes, I look after an Apache installation with hundreds of web sites, most are name-based. It's a shared infrastructure with dynamic content allowed, in a single apache instance. Within these parameters we try and make it as secure as possible. We can use unix-level system resource monitoring for quite a lot of things, but having all content delivered by a single user (the apache generic user) presents us with all sorts of problems, not least of which is protecting that apache user from running user's code (e.g. we use suexec, disallow execs in ssi, do not use things like mod_perl). I'd like to ditch the current model of using suexec, to a perchild model. If there aren't other problems (perhaps other modules creating file descriptors) then this would seem a sensible way forward, removing the need for suexec and opening the possibility that we could offer dynamic content module providers (mod_perl etc) in a secure way to our users. Best wishes, James -- James Ponder; www.squish.net; London, UK
