On Friday 20 July 2012, Steinar H. Gunderson wrote: > On Fri, Jul 20, 2012 at 01:48:33PM -0400, Jeff Trawick wrote: > >> Why would you keep mpm-itk separate but mod_privileges not?
On reason may be that (at least in theory), mod_privileges is more secure: Under Solaris you cannot get uid 0 unless you already have all privileges, so an exploited httpd with mod_privileges does not give you root. Under Linux however, CAP_SETUID is equivalent to full unrestricted root, because it allows you to write to root owned files (like /etc/crontab or /root/.ssh/authorized_keys). > > IMO it is not a very relevant question given the big picture: > > > > * Most modules written for httpd are not bundled with the server > > or otherwise hosted/developed at the ASF. > > * mod_privileges is for a minority server operating system and is > > not used extensively even there. > > * You won't find much rhyme or reason to why some modules are > > bundled and some are not other than whether or the author has > > commit access, and even then there isn't much consistency. > > I'm not sure if I understand this. Should not “the module is > considered useful” be a better criteria than “the module is > written by someone with commit access”? And how can “the module > has a very small user base” be an argument _for_ keeping it in > trunk, and the more popular one out? > > If nothing else, should not a module that's patched in by a > significant fraction be pulled into the main tree, to lighten the > burden on distributors? It also a question of the expected maintenance overhead and the available man-power. For example, according to Debian's popcon, mod_fcgid has around three times as many users as mpm-itk, but it is not part of core httpd either. One of the reasons is that not enough active developers are really interested in mod_fcgid. > > As far as mpm-itk: A few hooks can be added to httpd core so > > that it can be enabled just like other modules*, whether or not > > anyone here cares about the implementation details. > > > > *Of course that isn't really true of the popular 2.2.x branch, > > but I don't think it is realistic to hope that mpm-itk would > > ever make it to 2.2.x anyway. > > If we can really get mpm-itk compilable out-of-tree without Apache > patches, that would certainly be a better situation than what we > have today. Yes, that would be a good thing. It would be even better if it could work as normal (non-mpm) module together with mpm-prefork. And if it gets secured to where a code execution exploit does not grant full root rights, I would probably be in favor of including it with httpd.
