httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Neulinger <>
Subject Re: setuid control WITHOUT running as root
Date Sun, 02 Jun 1996 17:59:54 GMT
> > I personally think it would be better to design any CGI modifications
> > (along the lines of suCGI) without thinking about setuid purposes...
> My approach is really no different than that of mod_sucgi. One advantage
> of my approach is that it centralizes the exec code where some of the
> initial safety checks are done. It is then easy for anything else in the
> server to use call_exec() to do the job.

Right, but a misconfigured sucgi.c is then a MAJOR security hole... A
misconfigured cgiwrap for example just won't work...

Your patch would be an excellent solution, but I think that sucgi.c needs
to have some security checks built into it as well...

> > This would isolate the Apache server from the major security concerns of
> > running setuid scripts and such, but at the same time would allow that
> > functionality to be added much more easily with add-on tools produced by
> > other people.
> How does my patch fail to address that?

The problem of the sucgi.c backend still being somewhat of a hole.

> > This could be extended to be thought of as a "data access filter" - where
> > accessing certain data could be passed through an external routine to be
> > accessed.
> There is already a fair amount of data access control in the server.
> How can we increase that without complicating the server more, or
> needing to include a very complicated wrapper?

Poor wording on my part.. by "access" I meant retrieval/fetching/viewing...

I.e. a internal server "viewer" for a particular type of data... The
"viewer" for a cgi script in a virtual host would be a binary that changed
id's to that virtual hosts userid.

-- Nathan

Nathan Neulinger                  Univ. of Missouri - Rolla
EMail:                  Computing Services
WWW:      SysAdmin:

View raw message