httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Sutherland <>
Subject Re: [PATCH] security - run mod_cgid's daemon under same user as Apache
Date Thu, 08 Jun 2000 12:26:48 GMT

> > Ideally, CGIs should be running as a user other than the httpd, I think.
> > Add an option CGIUser to control this?
> I guess I'm pretty ignorant here.  I thought that suexec covered that
> issue and that hopefully it could be shoehorned to work with
> mod_cgid.  For now, I think I'll just put something in the STATUS file
> (don't let me forget :) ).

Good point. I would want CGIs running as the file owner, I think? This
will require some work on cgid...

> > That'll secure the socket from any evil users; with the t bit on the
> > directory, only Apache can delete the socket, and only the cgid or Apache
> > can open it.
> The t bit isn't needed on the directory because it lives in
> prefix/logs, and the logs directory isn't world-writable (unless the
> admin does something stupid).
> Only the cgid or Apache can connect() to it by virtue of the
> permissions (rw-------) and owner (Apache user id).

OK. I was suggesting having it owned by the cgid user id instead, but that
would do...

(In fact, cgid will need to start as root then setuid to the file owner,
once we add suexec functionality, anyway, so no problems there.)

> > That looks good. Is it possible to append the PID to the socketname? This
> > will ensure it's unique if two copies of Apache are running at the same
> > time with the same config. We need to unlink() the socket on exit,
> > ideally, to ensure the directory doesn't get cluttered; just checking for
> > (eg) cgisock.`cat` on initialisation, before is
> > updated, should do most of this work.
> How about for now I put something in the STATUS file (under
> non-showstoppers) for suggested mod_cgid enhancements related to the
> socket? 
> a) add .pid to the cgisock pathname
> b) remove the cgisock socket when Apache goes away
> The more new function I'm testing at once, the greater the chance of
> it not being correct.

+1. I'll have more time in a week or two; unless there's a mad rush to
implement this, I'll take a look then?

> Thanks for your comments!



View raw message