Bug 178844 - xinetd only_from and no_access controls ignoring wildcards and CIDR netmasks
Summary: xinetd only_from and no_access controls ignoring wildcards and CIDR netmasks
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: xinetd   
(Show other bugs)
Version: 4.0
Hardware: i386
OS: Linux
Target Milestone: ---
: ---
Assignee: Jay Fenlason
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2006-01-24 19:17 UTC by Stuart Sears
Modified: 2014-08-31 23:27 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-05 20:00:24 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Stuart Sears 2006-01-24 19:17:49 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.0 (like Gecko)

Description of problem:
in /etc/xinetd.d/<service> 
no_access = 
only_from = 
no_access = 
only_from = 
both fail to permit access from 
no_access = 
only_from = 
works as expected, as described in the xinetd.conf(5) manpage. 
both trailing zeroes (as wildcards) and CIDR netmasks are supposed to be 
honoured.(in fact VLSN netmasks are not even mentioned in the manpage) 

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

How reproducible:

Steps to Reproduce:
1. install telnet-server 
2. add either of the access control examples listed above to 
3. chkconfig telnet on 
4. attempt to connect from the the host specified in 'only_from' 
5 look in /var/log/messages, you should see a message similar to: 
Service=telnet: only_from list and no_access list match equally the address 

Actual Results:  when the no_access network was specified either as or 
xinetd seems to consider this just as specific as 
when is clearly a more precise match for that specific IP address. 
Because xinetd believes that matches equally on both access 
controls it is denying access. 

Expected Results:  In all three cases, should be granted access and all other hosts 
in should be denied. 
xinetd should recognise and as less specific than 

Additional info:

Comment 1 RHEL Product and Program Management 2006-09-05 19:45:59 UTC
The component this request has been filed against is not planned for inclusion
in the next update. The decision is based on weighting the priority and number
of requests for a component as well as the impact on the Red Hat Enterprise
Linux user-base: other components are considered having higher priority and the
number of changes we intend to include in update cycles is limited.

Comment 2 RHEL Product and Program Management 2006-09-05 20:00:28 UTC
Product Management has reviewed and declined this request.  You may appeal this
decision by reopening this request. 

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