httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joshua Slive <>
Subject Re: [users@httpd] Apache permission problem: No fix planned in near future...
Date Wed, 06 Nov 2002 18:33:17 GMT

On Wed, 6 Nov 2002, zeno wrote:
>  Does anybody else on this list find it disturbing that a well known
> vendor such as apache acknowledges
>  a problem, and rather then fixing it blame the third party module
> coders because of their API design
>  flaw?

As has been pointed out to you several times, this is not some amazing new
problem you have discovered.  This is a basic constraint of existing
server-side technologies in the unix world that is very well known to
anyone with a basic knowledge of the web.  If you think you're going to
get it fixed by badmouthing sincere and very knowledgable volunteer
developers, then you are mistaken.

Getting back to the issue, there are several ways to work around the

1. Do not give cgi or other server-side programming access to non-trusted
users.  This is a basic principal of web-server management that is clearly
documented and very well known.

If you must violate number 1, then there are some options:

2. Use a restricted environment like mod_include's IncludesNoExec or php's
safe mode.

3. Use a suid wrapper like suexec or cgiwrap.

4. Use an out-of-process apache module like mod_fastcgi to separate
the programs from the main server.

4. Isolate the server that handles the user-supplied programs by running
multiple servers fronted by a proxy, or using the (experimental) perchild
MPM in apache 2.

5. Change apache.  How you would do this is not an easy question, given
the basic constraints of the unix permission model.  The most likely
solution would be a process-separated API, which could wind up looking
much like mod_fastcgi.  The other solution is perchild, which is already
under development.

The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message