CERN httpd identd bug identified

CERN httpd identd bug identified

Post by Glenn Fleishm » Thu, 11 May 1995 04:00:00

This may have been reported before. If so, I never saw the report.

We discovered that enabling the Configuration Directive

IdentityCheck Yes

may cause a 30-second hang per connection (not request) if the remote
site has not properly configured the ident daemon. It's unclear exactly
why this is. We're supposing that at these sites, the identd has been
left in the services and inetd.conf files (or equivalents) but there is
no identd actually running. The 30 seconds may be the timeout.

In any case, a few points are clear
* It doesn't occur in every case
* It occurs only at a few sites ( being identified as one of
them, not to single them out but to provide a test case)
* Setting IdentityCheck to No removes the problem entirely

In the CERN httpd 3.0 docs, it mentions that enabling this directive
might cause some delays. But 30 seconds seems excessive. I'm sure
hacking the daemon would make it possible to have  500 ms timeout or
some such on the server end.

Glenn Fleishman * Point of Presence Company <>
      Contributing Editor, Adobe Magazine
      Moderator, Internet marketing list and Web Critique list


1. Bugs in CERN Httpd (Daemon/Implementation/HTDaemon.c) + a fix

I found that it goes into a tight loop upon receipt of SIGTERM.

Upon tracing this, I found that it was getting an error on the
accept() and looping back and trying it again.  So, looking
in the SIGTERM handler routine, I find all it does is *attempt*
(more on this later) to kill its children and close its listening
socket -- no wonder the accept() gets an error, eh?  So I added
a call to exit() too:

PRIVATE void sig_term NOARGS
    if (sc.standalone) {
#if defined(__svr4__) || defined(_POSIX_SOURCE) || defined(__hpux)
        kill(-pgrp, SIGKILL);
        killpg(pgrp, SIGKILL);
        shutdown(master_soc, 2);
        exit(1);                       /* Added by me */

Perhaps it should go outside the "if (sc.standalone) ..." block
(I dunno, I never run it any other way), but it's hard for me to
determine what the heck the origial author intended to happen.

As for attempting to kill its children, the pgrp is set wrong
in daemon_start() in the #else clause, it should be:

#if defined(__svr4__) || defined(_POSIX_SOURCE) || defined(__hpux)
    pgrp = setsid();
    pgrp = (setpgrp(0, getpid()) == -1) ? -1 : getpgrp(0);

[setpgrp returns -1 or 0, not the pgrp]

John Hascall                   ``An ill-chosen word is the fool's messenger.''
Moderator, comp.unix.wizards
Systems Software Engineer, ISU Comp Center  +  Ames, IA  50011  +  515/294-9551
<a href=""> My Homepage </a>

2. Token ring and 2.0

3. A question about the CERN httpd and Linux bug

4. Is there a solution with VIBRA16 problem?

5. Bug(?) with cgi scripts under CERN httpd

6. File Transfer over Telnet

7. Bug in CERN httpd v 3.0A on HP-UX ver 10 ?

8. Apache default page if none exist

9. bug in cern httpd with the protection rules ?

10. CERN httpd: Suppressing CERN Reference on authorization failures

11. CERN ftp server can't open PASV for CERN httpd 3.0

12. cern-httpd - proxy-cache - httpd.conf WANTED ???!!!

13. translator from CERN httpd configuration rules to Apache httpd conf?