Re: CGI security on a shared web server (fwd)From: Steffen Dettmer (firstname.lastname@example.org)
Date: Fri, 31 May 2002 21:56:03 +0200 From: Steffen Dettmer <email@example.com> To: firstname.lastname@example.org
* Lee E. Brotzman wrote on Wed, May 29, 2002 at 17:28 -0400:
> On Wed, 29 May 2002 11:04:30 +0200, Steffen Dettmer said:
> > SuEXEC already does setuid to the owner of that script - and
> > I think it may even refuse execution if setuid bits are set.
> > At least SuExec makes some tests, check docs.
> outweigh the risk of running all CGI programs with a real userid. Of the 30 or
> so CGI programs in the project, only 8 had to have any elevated privilege. The
> rest were just fine running as user "web" or whatever the web server UID was.
This is not the problem! The reason for SuExec is quite
different. If you have multiple (human) users on the same web
server, you cannot allow that all that scripts run as the same
wwwrun or nobody user. In this case the script from user A could
read a script from user B and could overwrite logfiles from a
script from user C, since all of them run as nobody (or
> the same UID as the web server. I think you're better off if there are no files
> owned by the UID of the web server, whether that's 'nobody' or some other
> special-purpose UID.
Well, but the files created by the scripts will be owned by that
UID, and if a CGI script can read some file, any user of that
server that is allowed to have CGI scripts can read it. This is
the issue SuExec was made for.
> I would hope that others would recognize that there are also
> reasons *not* to use it.
Yes, there are, but I think in such cases this will also work
with suExec. So we just it everywhere, just to go for sure :) And
if later some user get's allowed to make CGI scripts, he can do.
-- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.