Red Hat Bugzilla – Bug 178844
xinetd only_from and no_access controls ignoring wildcards and CIDR netmasks
Last modified: 2014-08-31 19:27:58 EDT
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 = 192.168.0.0 only_from = 192.168.0.4 and no_access = 192.168.0.0/24 only_from = 192.168.0.4 both fail to permit access from 192.168.0.4 however no_access = 192.168.0.0/255.255.255.0 only_from = 192.168.0.4 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): xinetd-2.3.13-4.4E.1 How reproducible: Always Steps to Reproduce: 1. install telnet-server 2. add either of the access control examples listed above to /etc/xinetd.d/telnet 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 192.168.0.4 Actual Results: when the no_access network was specified either as 192.168.0.0 or 192.168.0.0/24 xinetd seems to consider this just as specific as 192.168.0.4 when 192.168.0.4 is clearly a more precise match for that specific IP address. Because xinetd believes that 192.168.0.4 matches equally on both access controls it is denying access. Expected Results: In all three cases, 192.168.0.4 should be granted access and all other hosts in 192.168.0.0/24 should be denied. xinetd should recognise 192.168.0.0 and 192.168.0.0/24 as less specific than 192.168.0.4 Additional info:
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.
Product Management has reviewed and declined this request. You may appeal this decision by reopening this request.