Nick Kew wrote: > "Steinar H. Gunderson" <[EMAIL PROTECTED]> wrote: > >> - setuid() happens after the request has been parsed, which means >> that the server runs as root up until that point. (However, on a >> system with capabilities, ie. Linux 2.6, almost all superuser >> privileges are dropped, so you can't just load kernel code or >> whatever.) > > First there's the obvious issue of any bugs in the core code > (which includes yours - if it goes in) going nuclear by running > as root. > > But secondly, it does the same for a lot of module code. Any > module that runs a connection-level input filter, such as SSL, > a protocol module, or a bandwidth-shaping module, is going to > have code run as root. That means a lot of existing third-party > code goes nuclear too. Including it in the core dist makes a > huge target! People get pwned, apache gets the blame.
This has been a design constraint from the very early days, which is why I expect your MPM would not be included in the core distribution. We have a very similar issue (to be solved differently) in mod_ftp, when the user insists that the data port must be bound to a low #'ed (traditional) ftp data port. Defining a block of high numbered ports through the router is the suggested way to go. That said, have you considered a design where there are separate pools of processes per-user, and these would be dispatched after the headers are processed to the appropriate child? Of course, this brings us back to perchild which has been longing for some time for more attention. But that said - your module does offer something to compliment perchild for users of thread-unsafe module designs, and provides the process separation that some admins desire. Bill
