Bug 770858 - Instances limit in xinetd can be easily bypassed
Summary: Instances limit in xinetd can be easily bypassed
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: xinetd
Version: 16
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Jan Synacek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-12-29 17:35 UTC by lee.machnay
Modified: 2012-03-31 03:01 UTC (History)
2 users (show)

Fixed In Version: xinetd-2.3.14-44.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-03-31 03:01:07 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description lee.machnay 2011-12-29 17:35:01 UTC
Description of problem:

The connections number is limited in the xined.conf file by setting the "instances" field.  However, when a connection is blocked after exceeding the “cps” limit, the xinetd “forgets” the existing instances and the instances limit can be exceeded.

Version-Release number of selected component (if applicable):

xinetd version : 2.3.14

How reproducible:

Always

Steps to Reproduce:

Let’s say we configure the ‘instances’ field in the xinetd.conf file to ‘3’ and set the ‘cps’ field to ‘1 10’ (1 connection per 10 sec) , have one telnet connection opened, and now make two more telnet connections one after another (quicker than the ‘cps’ limit which is currently set to 10 sec). The first one will connect fine, and the second one will be blocked due to exceeding of the ‘cps’ rate limit. Once the connection has been blocked,  now 3 more connections can be configured. Now we have 5 connections opened, despite the fact that the instances limit is configured to 3.
  
Actual results:

Instances limit is not restricted. Xinetd forgets spawned connections.

Expected results:

When we exceed the number of instances connected, the connections should be blocked by the xinetd.

Additional info:

Same goes for ssh connections.

Comment 1 Jan Synacek 2012-03-05 14:23:34 UTC
Fixed in rawhide:
http://lists.fedoraproject.org/pipermail/scm-commits/2012-March/746307.html

Comment 2 Jan Synacek 2012-03-06 09:31:50 UTC
I've created a scratch build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3857239

Please, help test.

Comment 3 lee.machnay 2012-03-15 15:26:29 UTC
build xinetd-2.3.14-44.fc18.i686 successfully tested on Fedore 16.

The issue has been resolved,
Thanks for your help.

Comment 4 Fedora Update System 2012-03-16 07:39:25 UTC
xinetd-2.3.14-44.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/xinetd-2.3.14-44.fc17

Comment 5 Fedora Update System 2012-03-16 07:47:59 UTC
xinetd-2.3.14-44.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/xinetd-2.3.14-44.fc16

Comment 6 Fedora Update System 2012-03-17 23:35:05 UTC
Package xinetd-2.3.14-44.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xinetd-2.3.14-44.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-4002/xinetd-2.3.14-44.fc16
then log in and leave karma (feedback).

Comment 7 Fedora Update System 2012-03-21 19:08:11 UTC
xinetd-2.3.14-44.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 8 Fedora Update System 2012-03-31 03:01:07 UTC
xinetd-2.3.14-44.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.


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