Red Hat Bugzilla – Bug 16729
inetd does not close connection when daytime service is called
Last modified: 2008-05-01 11:37:58 EDT
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.
Created attachment 2818 [details]
Patch for reported bug
*** This bug has been marked as a duplicate of 11548 ***
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
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.
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.
Package is rolled. Pick it up from http://www.platypus.bc.ca/~bishop/software/inetdfix/ and test it.
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.
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.
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.
*** Bug 21740 has been marked as a duplicate of this bug. ***
Can you try the new one at http://people.redhat.com/teg/ ?
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?
It's easy to make a script connect to the daytime server continuously to trigger
Any bad results so far? I've gotten one mail about
inetd: select: Bad file descriptor
happening, but can't reproduce this (6.2, all updates and this) after 20+ k
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...
And now there is a -7, which I'll give QA.
Should be fixed in inetd-0.16-7, coming as an errata now.
*** Bug 18213 has been marked as a duplicate of this bug. ***
*** Bug 26899 has been marked as a duplicate of this bug. ***
*** Bug 44722 has been marked as a duplicate of this bug. ***
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.