The following reply was made to PR suexec/1769; it has been noted by GNATS.
From: Gary Shea <[EMAIL PROTECTED]> To: Dean Gaudet <[EMAIL PROTECTED]> Cc: Gary Shea <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: suexec/1769: suexec too limited -- need per-directory control, more permissive directory structures Date: Wed, 4 Feb 1998 15:07:48 -0700 (MST) On Wed, 4 Feb 1998, Dean Gaudet wrote: > On 4 Feb 1998, Gary Shea wrote: > Why is it that people paint us as mean awful ogres all the time? I'm sorry about that. The rigidity of suexec put me off a bit, but it's no excuse for being harsh. > Heck you shouldn't even need patches to do this if > you're willing to do the directory -> user mapping outside of apache. > Just use the same model that cgiwrapper uses. i.e. something like this: > > RewriteEngine on > RewriteRule ^(.*)\.cgi /usr/local/apache/my-fancy-cgi-wrapper/$1 > [T=application/x-httpd-cgi] > > (Not that I've tested that example.) > > Dean I'll look carefully at that idea, it's promising, now that the rewrite module can eliminate the need to manually change thousands of HTML pages. And when the work I've already done expires due to the next release of 1.3, well, it might look even more attractive! The approach I've taken so far (and will go ahead and finish since it's basically done) is to use the UserID and GroupID directives sugid introduced into mod_cgi, and pass the results to call_exec as two additional arguments. It's fairly clean, but meant moving the /~user detection from call_exec to mod_cgi, since that's where the uid/gid is determined. I dunno if that's a sticking point. Then I've hacked suexec to suck up a startup file containing a few directives: UserDirSuffix: public_html UserDirectories: on Directory: /blah-blah/cgi-bin Directory: /other-blah-blah/cgi-bin Directory: /some-blah-blah/cgi-bin/dibble Frankly, I could care less about UserDir* since I have no such users to worry about, but just to be complete... ;) This stuff could be compiled in but that would be a PAIN, since I'm always adding new virtuals. When uname, gname, fname are presented to suexec I check the user's home directory + '/' + UserDirSuffix for a match; if none, check the directories list for a match (which can be very fast); if none, error out. (The suexec ~user uname hack had to go, too bad -- it was good for efficiency but too ugly to propagate through call_exec, in my opinion.) This frees me from the constraints of stock suexec, without (I think!) unreasonable additional security exposure, but at the cost of loading a startup file for every cgi. Yuck! The right way is probably to turn suexec into a simple forking server (on a unix socket) in its own right (which seems a bit silly but useful at the same time). I might go ahead and do it, just cuz it's easy. One more thing to go wrong, sigh... as always, it's the error handling that really bites. I believe the fancy-cgi-wrapper approach shares the need to startup and read a list to make sure it's ok to do what it's being told to, if it's not exec'ing in a user's home directory, so while it doesn't involve hacking Apache it also isn't the highest performance solution available. I'll send in patches when things are cleaned up, if I haven't heard any comments/suggestions by then. ----------------------------------------------------------------- Gary Shea [EMAIL PROTECTED] Salt Lake City http://www.xmission.com/~shea
