Cobalt RaQ 3 security hole?

[cday () BEACHASSOCIATES COM (Chad Day)]

This may not be a true alert, I'm a bit of a newbie at security, but this is
just screaming out to me.

I'm working for a client on a freelance project who is running a Cobalt RaQ
3.  I needed to rebuild Apache to compile in PHP4 support.

So, I do this, yadda yadda..

The server is running 2 copies of apache.  The standard one on port 80, and
"admserv" on port 81, which is the web administration interface.

I take my newly compiled httpd, back up the old one in /usr/sbin, and
restart both copies of apache.  The standard one comes up fine.  The
"admserv" one refuses to start.

[root@cb029 admin]# /etc/rc.d/init.d/admserv start
Starting admin web server:
Error:  Apache has not been designed to serve pages while
        running as root.  There are known race conditions that
        will allow any local user to read any file on the system.
        If you still desire to serve pages as root then
        add -DBIG_SECURITY_HOLE to the EXTRA_CFLAGS line in your
        src/Configuration file and rebuild the server.  It is
        strongly suggested that you instead modify the User
        directive in your httpd.conf file to list a non-root
        user.

Obviously, running apache as root is a Bad Thing.  I check their
configuration files, and sure enough the httpd.conf for admserv is set to
run as root/root.  I change this, it starts up fine, but then the admserv
interface breaks, with errors like:

[Sun Jul 23 05:58:10 2000] [crit] [client xx.xx.xx.xx] configuration error:
couldn't check user.  No user file?: /cgi-bin/.cobalt/backup/backupmenu.cgi

Those errors do not appear if the webserver is running as root, which I put
the old httpd back on and tested to verify.

WTF?  Is it standard for Cobalt servers to compile Apache with the
BIG_SECURITY_HOLE flag and run admserv as root/root?  Is this just a local
issue, something whoever installed this on on the server did initially?  I
obviously do NOT want to compile my copy of apache with BIG_SECURITY_HOLE
just to get the admin interface working.  The only thing I can think of is
changing the permissions on all the admin interface files to let another
user execute the scripts, but is that going to open up something else?

I highly suspect this is not an issue with all Cobalt RaQ 3's, because
someone else would have had to come across this.  Can anyone clue me in on
what I did wrong, if anything?

Thanks,
Chad