Bug 16729 - inetd does not close connection when daytime service is called
Summary: inetd does not close connection when daytime service is called
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: inetd
Version: 6.2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Trond Eivind Glomsrxd
QA Contact:
: 18213 21740 26899 44722 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2000-08-22 15:28 UTC by Karl Hakimian
Modified: 2008-05-01 15:37 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2001-01-30 00:31:35 UTC

Attachments (Terms of Use)
Patch for reported bug (2.34 KB, application/octet-stream)
2000-08-22 15:29 UTC, Karl Hakimian
no flags Details

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2001:006 normal SHIPPED_LIVE : Updated inetd packages available for Red Hat Linux 6.2 2001-01-25 05:00:00 UTC

Description Karl Hakimian 2000-08-22 15:28:38 UTC
Inetd does not close the connection on non-forked services. This results
in the error "Too many open files" after inetd has been running for a

The solution seems to be to add a close on the non-forked service. Since
there will be no waiting on a non-forked service, there does not appear
to be a need for any checks before the close.

I will attach a patch for this.

Comment 1 Karl Hakimian 2000-08-22 15:29:36 UTC
Created attachment 2818 [details]
Patch for reported bug

Comment 2 Pekka Savola 2000-08-22 21:08:19 UTC

*** This bug has been marked as a duplicate of 11548 ***

Comment 3 Karl Hakimian 2000-08-25 15:26:54 UTC
I disagree with your description of this as a duplicate of bug
11548. Bug 11548 is for rawhide which no longer uses inetd and therefor
no fix is being released. A fix for 6.2 needs to be released.

My reasons for disagreeing are as follows

1) Since it is broken in 6.2 a 6.2 update needs to be released

2) After thinking more about this bug, I realized that I should have
reported it as a security bug since it makes a denial of service attack
on a machine using the internal services very easy. It does not even
require a fast connection, just request the time service from a host
serving it up a few thousand times over a week or so and that server is
in trouble.

3) It is not uncommon for a site to active the time and/or daytime
service to monitor and or synchronize time on machines. This practice
will cause said machines problems over time even without a malicious
user helping them along.

Since you posted a patch in bug report #11548, I can't understand why
you did not also post a new RPM.

RedHat's decision to not release a new RPM for a potential security
problem can't look good for RedHat specifically or Linux in general.

Comment 4 Bishop Clark 2000-10-13 13:48:28 UTC
We're almost 60 days on a DoS security problem here.  Is this a concern for anyone else ? (I mean besides me,
 whose internal net is killin his NAT box via the daytime svc )

I'm gonna roll an inetd.rpm .  I'll post here and freshmeat.

Comment 5 Bishop Clark 2000-10-13 16:21:53 UTC
Package is rolled.  Pick it up from http://www.platypus.bc.ca/~bishop/software/inetdfix/ and test it.

Comment 6 Tom Cross 2000-11-20 14:48:59 UTC
Thanks much for the rpm.  I'm eagerly waiting for an official RedHat response to

Many of us NEED the functionality of a day/time server.

Comment 7 Elson, Del 2000-12-01 22:32:46 UTC
2 Dec 2000 and there is still no official Red Hat RPM for this simple bug.
It has shown up on bugzilla as 10767, 10786, 11545, 12779, 14687, 14876 and
16729.  This is a high priority security bug, haven't Red Hat been convinced
that a fix is required yet?

I don't care about inetd being replaced in rawhide, I don't want to use rawhide
on a production system, I want to use the good old stable RH 6.2 thanks.


Comment 8 dbergstein 2001-01-25 01:39:05 UTC
Please fix this issue ASAP - it is affecting other services like kerberos as
well.  When inetd has the "too many open files" error, I cannot use encrypted
kerberos telnet sessions until I manually restart the offending server.

Comment 9 Trond Eivind Glomsrxd 2001-01-25 18:38:37 UTC
*** Bug 21740 has been marked as a duplicate of this bug. ***

Comment 10 Trond Eivind Glomsrxd 2001-01-25 19:23:53 UTC
Can you try the new one at http://people.redhat.com/teg/ ?

Comment 11 dbergstein 2001-01-26 03:47:33 UTC
I downloaded and installed the version from http://people.redhat.com/teg/

Normally it takes at least a week for this problem to occur.  Is there a load test that would simulate/stimulate this issue or would you like me to reply again sometime next week?

Comment 12 Trond Eivind Glomsrxd 2001-01-29 21:21:28 UTC
It's easy to make a script connect to the daytime server continuously to trigger
the problem...

Any bad results so far? I've gotten one mail about

inetd[7923]: select: Bad file descriptor

happening, but can't reproduce this (6.2, all updates and this) after 20+ k

Comment 13 Trond Eivind Glomsrxd 2001-01-29 23:10:46 UTC
New RPMs (-6) are available at http://people.redhat.com/teg/

If those who have had problems can test these, and mail me whether it fails or
not, that would be nice. It's survived 60+k connections without problems so far...

Comment 14 Trond Eivind Glomsrxd 2001-01-30 00:31:30 UTC
And now there is a -7, which I'll give QA.

Comment 15 Trond Eivind Glomsrxd 2001-01-30 16:45:22 UTC
Should be fixed in inetd-0.16-7, coming as an errata now.

Comment 16 Trond Eivind Glomsrxd 2001-01-30 16:49:20 UTC
*** Bug 18213 has been marked as a duplicate of this bug. ***

Comment 17 Trond Eivind Glomsrxd 2001-02-10 22:16:46 UTC
*** Bug 26899 has been marked as a duplicate of this bug. ***

Comment 18 Jeff Johnson 2001-06-15 20:22:39 UTC
*** Bug 44722 has been marked as a duplicate of this bug. ***

Comment 19 Bishop Clark 2001-06-17 22:06:03 UTC

Did you *read* my bug report?  Can you read?

I'm not talking about inetd-0.16-5 here, the DoS problem  that RH took *six months* to address and then finally roll someone else's fix into;  I'm talking 
about a NEW problem with the apparently fixed binaries here.  Had you taken more than 5 seconds to glance at 44722, you'd have seen that.  You didn't 
did you?  How about looking at 16729, to which I've posted.  See that?  Maybe I've seen this bug report, since I posted in it, and decided it didn't fit, 
because I'm apparently using *fixed binaries*, *as* *I* *mentioned*.

I know.  It's hard work to act like you know what you're doing.  Try a little harder.  Read 44722 again, make a half-hearted effort to reproduce the situation 
- for show - and then pronounce it as NoRePro. Then go back to your net.comics or something.

Note You need to log in before you can comment on or make changes to this bug.