httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Skolnick <>
Subject ap_uname2id(), nis+, suexec, and virtual hosts
Date Fri, 19 Mar 1999 05:45:43 GMT

I traced it down a transient problem with a client, who is an ISP hosting
many virtual hosts on each system.  Sometimes after a script adds a new
virtual host the web server does not start.  The script is automated, so it
pretty quickly modifies the httpd.conf and restarts the web server.

This is all fine, unless the user is a new user just added to nis+, and the
replica (which can take up to 10 minutes to get some of the data) is queried
by the web server.  With virtual hosts and suexec, the server tries to look
a username in the password database, but before it is there.

Unfortunately in ap_uname2id(), if the getpwnam() fails an exit(1) is
immediately called.  There is no chance for the web server to do anything
intelligent like disabling the virtual host and printing a warning message.

The function ap_uname2id() is part of the exported API, so it can't be
easily changed from:

API_EXPORT(uid_t) ap_uname2id(const char *name)


API_EXPORT(int) ap_uname2id(const char *name, uid_t *uid)

without causing a hassle.  (ap_gname2id also has this problem)

It does not seem reasonable that looking up a bad user name or group is
always fatal to the web server.  I am suggesting that either the API is
changed - which is hard, or that a ap_uname2id_2 is added.  We can also do
#define tricks to have one actual C function with two behaviors.


note about the API:  When valid return data needs the whole value range, it
is hard to return error status by overloading the function type.
ap_uname2id() really can not return a -1, 0, or 1 for an error condition
since they all are quite valid users.

PS The #ifdef for win32 just returning 1 is kind of scary.  I would think an
error would be returned and the calling function should have the #ifdef
win32's to handle the situation in an appropriate manner.

Cliff Skolnick
Steam Tunnel Operations

View raw message