Switching bugzilla suEXEC => mod_cgi

[Owen Taylor <otaylor redhat com>]

Currently, we are using "suEXEC" to execute bugzilla - apache changes
to to bugzilla user before running the CGI scripts. So the private
files are readable only to the bugzilla user, the data directories
are writable only by the bugzilla user, etc.

This setup was done to provide isolation between Bugzilla and other web
services on gnome.org. Bugzilla has always been some of the highest
value data stored in a database on gnome.org, so we'd rather a
programming bug in some other web service didn't allow modifying data in
the bugzilla database. (And, to a lesser extent, the reverse.)

Max would like to switch things over to run via mod_perl.

The primary advantage of mod_perl is the standard one of reducing load
time since a separate Perl interpreter doesn't have to be created
per-page. (Max mentions a 6-time improvement for some pages.)

With mod_perl we can't use a separate user/group to get isolation; on
the other hand, we are planning to switch to a dedicated bugzilla
frontend virtual machine, so we have some other techniques at our
disposal.

Specifics:

 Access to the bugzilla database password:
 
  The web server needs to be able to read the password. If the password
  lives in /home/admin/, then web services on other machines will be
  able to read it as well. We can either:

   - Store the password locally instead of in /home/admin
   - Lock down the bugs database so the password only works from
     bugzilla-back

  According to Max, current bugzilla is not happy with our approach
  of a private.pl including the database password. But we can put the
  entire localconfig somewhere else.

  Our general policy is not to have passwords in any directory that
  is directly mapped into the web hierarchy, so we probably want to do
  that here. It can just go in the bugzilla home directory
  /usr/local/www/bugzilla.

 Preventing access to other passwords:

  Other passwords are stored in /home/admin readable to the apache
  user/group. We can:

    - Not worry about it
    - Lock down other databases so their passwords only work from
      the appropriate web frontend machines
  
 Writing data

  The apache process needs to be able to write data in 
  $bugzilla_dir/data/. As long as the bugzilla data directory isn't
  mounted on any other machines, there's no risk of other web services
  having inappropriate access.
 
  In order to get the permissions on $bugzilla_dir/data/ set up
  correctly, checksetup.pl expects to be a able to set the permissions
  to the apache group.

  Making the bugzilla user member of the apache group would allow
  this without sysadmin assistance. There's no security downside to
  this - if the bugzilla code is editable as the bugzilla user, it 
  can do anything as apache anyways.

  I went ahead and did this - was rather painful to do in puppet, 
  because bugzilla is a LDAP user and apache a local group, but
  a small python script and an 'exec' managed it.

Alternate approach

 We could run httpd as the bugzilla user. Sounds like there would be
 a lot of small details to fix up. Goes against wanting to use the
 standard apache httpd configuration.

- Owen