In this issue

1.0.5 is the current stable public release. The beta test version, 1.1b, is still at version 2, with 1.1b3 to be released very soon.

Apache has continued to gain users, and a recent survey suggests that a third of all public web servers run Apache. The June 1996 Netcraft Web Server Survey looked at 252,685 servers, and places Apache at 33%, NCSA 22% and Netscape 16%.

All: Linux core dumps with mod_include

As reported last week, Apache with Linux libc.5.3.* was causing core dumps for some people. The problem was with the mod_includes module, which was core dumping on every file being parsed for server-side includes. A fix in now available and will be incorporated into 1.1.

Inetd version ignores User and Group

When Apache is run from inetd, it ignores the User and Group directives. The idea was that the inetd configuration would specify the real user to run Apache. This might not be a bug, but requires documenting.

Expires sometimes missing

Mod_expires was not adding expiry time to responses that used the default content type. Fixed in next release.

Better mime types

The mime.types file (in the confs directory) tells Apache how to map file extensions onto mime types. The mime type tells the browser what to do with the file it has obtained. For example, a mime type of text/html should be displayed as an HTML document, while a file returned as mime type video/mpeg should be should in an MPEG player. The mime.types file that comes with Apache will be updated to incorporate new mime types, such as ReadAudio, VRML, Java, CoolTalk and PNG.

Non-IP virtual hosts

Last week's Apache Week explained how the new HTTP/1.1 protocol forces browsers to send a Host: header, so that virtual hosts could be implemented without using additional IP addresses. Apache 1.1 will support the Host: header, and a document explaining a relatively simple way to implement this for both old and new browsers is now available.

Multiple config files

Apache is configured by the files in the confs directory (srm.conf, access.conf and httpd.conf). These are normally owned by the administrator, since letting users write to them could be disastrous! However, on sites with virtual hosts, it would be nice to let the owner of the virtual host be able to maintain at least some of the configuration directives which apply to that virtual host. This could be done with something like an 'Include' functionality, to read external config files. There are a number of issues to resolve, however, such as how to limit what directives are valid in external config files, what to do if the external file contains errors, and how to notify Apache to re-read the config file (since the virtual host owner cannot send it a HUP signal).

Incidentally, although Apache comes with three config files (the srm.conf, access.conf and httpd.conf files), it treats them all identically. So all the configuration could take place in a single file - httpd.conf (which is the first one read). This file should include the directives

AccessConfig    /dev/null
ResourceConfig  /dev/null

to prevent it complaining about the missing srm.conf and access.conf files.

CGI programs always run as the same user that owns the Apache server process. This is set with the User directive in the config file, and is typically a normal user such as 'www', or the 'nobody' user. In most cases, this is fine, since CGI scripts should run with few privileges to limit any potential malicious damage to the system. However, in some cases it would be nice to be able to run CGI programs as other users. For example:

• On a virtual host system, with multiple customers, CGIs could run as the customer's user, to let them read and write to the customer's files.
• On other systems with multiple users, CGIs in home directories could run as that user.

The ability to run CGI programs as other users is referred to as 'running setuid', after the Unix filesystem ability to run a program as another user. The biggest problem with having a setuid CGI facility on a web server is security. It has to be very careful to ensure that the program running setuid cannot be invoked to do malicious damage to the system. Having setuid programs on a system can be dangerous, particularly if you do not trust all the other users on the system (which would be the case with both the example above). The risk is that other users could run the setuid program manually (from the command line) and give it an environment or command arguments that make it perform undesired activities. The risks of setuid programs are well-known to Unix system administrators, but a lot of web administrators do not have so much experience of Unix or setuid security programming.

There are a number of utilities to make CGI scripts run setuid to a user other than the owner of the server process, so that server administrator does not have to worry too much about these issues. These utilities work by having a small 'wrapper' that is itself a setuid CGI program, that then invokes the (non-setuid) CGI program itself. If the wrapper takes sufficient precautions it can be relatively secure. Examples of programs to implement this are:

• CGIwrap, which is a setuid CGI wrapper program. To refer to a setuid CGI script requires a special URL syntax.
• sucgi, which is a wrapper plus an Apache module to replace mod_cgi. This handles doing setuid for programs in UserDir directories automatically, without special URL syntax.

Anyone using either of these programs should be very careful to ensure that security is not compromised (and some of the ways that this can be done are very subtle). At present, suCGI only works for UserDir requests, not virtual hosts. Doing this securely with something like suCGI is the subject of much debate amongst the developers.

One of the uses of a secure setuid CGI environment would be for the Microsoft FrontPage server extensions. These extensions require write access to the files they can update, but unfortunately this could mean giving all FrontPage users the ability to update any pages on the site. It would be nice to be able to ensure that the FrontPage extension could only write to a subset of files, perhaps by using some sort of setuid extensions.

CERT have issued a security advisory about the dangers of putting general-purpose interpreter programs such as sh and perl in a CGI directory. The dangers of these should be obvious to anyone familiar with CGI programming, but a quick survey revealed a number of sites with interpreters in their cgi-bin directories. This is not an Apache problem - it can occur with any server that supports CGI. It has mostly been a problem on Windows-based sites, and one server vendor even recommended NT users place perl.exe in their cgi-bin directory (they now provide better advice). More details of security issues when writting CGI programs are available from the The World Wide Web Security FAQ.

Mozilla vs. Apache: c|net reports on Netscape's response to Apache's continued success.

Apache über alles?: Following Apache's number one rating in the Netcraft survery, the German iX Magazin has published an article on configuring Apache. It is available in both English and German.