Dear Wiki user, You have subscribed to a wiki page or wiki category on "Httpd Wiki" for change notification.
The following page has been changed by noodl: http://wiki.apache.org/httpd/Recipes/Privilege_Separation The comment on the change is: mod_fcgi(d) and remove use of 'setup' as a verb ------------------------------------------------------------------------------ Even in cases where you would ordinarily use an Apache httpd module like php or mod_perl, the simplest, safest, and most performant way to get privilege separation will often be to instead use php or perl as a CGI script under suexec or cgiwrap. For php in particular, [http://www.suphp.org/ suPHP] provides an suid launcher (like suexec) combined with an Apache httpd module that makes configuration of PHP as a CGI somewhat easier. - In cases where the performance hit from using CGI scripts is not acceptable, the best alternative is often to use [http://www.fastcgi.com/ fastcgi] to run long-lived cgi processes outside the httpd process. The most up-to-date fastcgi module for Apache httpd is [http://fastcgi.coremail.cn/ mod_fcgi]. Work is currently underway to incorporate fastcgi management into the Apache HTTP Server distribution for a future version. + In cases where the performance hit from using CGI scripts is not acceptable, the best alternative is often to use [http://www.fastcgi.com/ fastcgi] to run long-lived cgi processes outside the httpd process. The most up-to-date fastcgi module for Apache httpd is [http://fastcgi.coremail.cn/ mod_fcgid]. Work is currently underway to incorporate fastcgi management into the Apache HTTP Server distribution for a future version. ''Be especially careful when configuring and using suid launchers like suexec, cgiwrap, and suPHP. These scripts allow the less-privileged Apache httpd user to do things beyond its standard permissions level (change userid, in particular). Any flaw in these programs or in your configuration of them can lead to serious security problems. The Apache HTTP Server developers have made every effort to keep suexec simple and secure. They cannot vouch for the security of third-party tools like cgiwrap and suPHP.'' @@ -32, +32 @@ If privilege separation is needed simply to keep administrators of one site from reading files deployed on another site, proper configuration of unix permissions will often suffice. - In particular, instead of making all files to be served by Apache httpd world-readable, setup a group such as {{{web-content}}} and run httpd under this group (using the Group directive in httpd.conf). Then site administrators simply place any content needed by the server in the {{{web-content}}} group with {{{chmod 640}}} (or similar) permissions. + In particular, instead of making all files to be served by Apache httpd world-readable, create a group such as {{{web-content}}} and run httpd under this group (using the Group directive in httpd.conf). Then site administrators simply place any content needed by the server in the {{{web-content}}} group with {{{chmod 640}}} (or similar) permissions. On some operating systems, much-more granular and flexible permissions management is also possible. For example, SELinux allows very precise assignment of permissions beyond what would be possible with the standard Unix permissions model. == Complete privilege separation using a reverse proxy == - If complete isolation of virtual hosts (or even particular URLs) is necessary, then the only real solution is to run a separate instance of Apache httpd for each host. When using IP-based virtual hosting, you can simply have each instance listen on a separate IP address. For name-based virtual hosting (or to isolate particular URLs with a virtual host), you can setup a reverse proxy server that dispatches requests to independent httpd instances on different ports. Full details are provided in [wiki:Recipes/Different_UserIDs_Using_Reverse_Proxy another recipe]. + If complete isolation of virtual hosts (or even particular URLs) is necessary, then the only real solution is to run a separate instance of Apache httpd for each host. When using IP-based virtual hosting, you can simply have each instance listen on a separate IP address. For name-based virtual hosting (or to isolate particular URLs with a virtual host), you can set up a reverse proxy server that dispatches requests to independent httpd instances on different ports. Full details are provided in [wiki:Recipes/Different_UserIDs_Using_Reverse_Proxy another recipe]. This solution is flexible, powerful, and very efficient (although the reverse proxy must double-process the http requests). It can, however, be complicated to configure for a large number of hosts.
