Bug 698464

Summary: IPv4 uses /n.n.n.n netmask, IPv6 uses /prefix notation
Product: [Fedora] Fedora Reporter: Philip Prindeville <philipp>
Component: tcp_wrappersAssignee: Jan F. Chadima <jchadima>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 14CC: jchadima, philipp
Target Milestone: ---Keywords: EasyFix, Patch
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-05-24 04:38:26 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Support for IPv4 /prefix notation
none
Support for IPv4 /prefix notation
none
Host byte ordering fix for the previous patch.
none
Host byte ordering fix for the previous patch.
none
Cosmetic fix to byteordering reversal none

Description Philip Prindeville 2011-04-20 22:34:53 UTC 
Description of problem:

Addresses for IPv4 use n.n.n.n/m.m.m.m notation, even though this is increasingly uncommon, inconsistent with most other Linux commands, and inconsistent with IPv6 notation.


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

7.6-59

How reproducible:

Use a "ALL: n.n.n.n/32" host address in a /etc/hosts.deny file, and then attempt to connect from that address.  The connection will not be blocked.

Steps to Reproduce:
1.
2.
3.
  
Actual results:

Address is not parsed correctly as an address/mask pair, therefore it isn't tested as an address/mask pair.


Expected results:

The connection should be blocked.


Additional info:

Note that /prefix is supported almost uniformly in other network applications.
Comment 1 Philip Prindeville 2011-04-20 22:55:48 UTC 
Created attachment 493652 [details]
Support for IPv4 /prefix notation

Installed and tested (verified) locally.
Comment 2 Philip Prindeville 2011-04-21 05:26:25 UTC 
Created attachment 493700 [details]
Support for IPv4 /prefix notation
Comment 3 Jan F. Chadima 2011-05-04 08:38:10 UTC 
patched in rawhide, test and report please
Comment 4 Philip Prindeville 2011-05-05 06:59:00 UTC 
(In reply to comment #3)
> patched in rawhide, test and report please

Can you point me at a x86_64 rpm? Koji builds? Thanks.
Comment 5 Philip Prindeville 2011-05-06 03:22:32 UTC 
Used fedpkg to build it.  Found a host order bug.

Attaching a fix for the patch.
Comment 6 Philip Prindeville 2011-05-06 03:23:48 UTC 
Created attachment 497273 [details]
Host byte ordering fix for the previous patch.
Comment 7 Philip Prindeville 2011-05-06 04:23:25 UTC 
Created attachment 497276 [details]
Host byte ordering fix for the previous patch.
Comment 8 Jan F. Chadima 2011-05-06 11:10:09 UTC 
Applied, test it again, please.
Comment 9 Philip Prindeville 2011-05-06 19:05:57 UTC 
(In reply to comment #8)
> Applied, test it again, please.

Works great...  Just realized, though, that attachment 497273 [details] (the first patch) was correct.  It should be htonl() and not ntohl() (even though they both do the same exact thing).
Comment 10 Philip Prindeville 2011-05-10 05:05:50 UTC 
Do you need anything else from me?

I'm thinking we should be good to go.
Comment 11 Philip Prindeville 2011-05-17 03:59:05 UTC 
Created attachment 499267 [details]
Cosmetic fix to byteordering reversal

prefix_to_netmask() should return network-order, not host-order value.

With this one-liner change, the fix should be good to go. Please close out this bug and release.
Comment 12 Philip Prindeville 2011-06-11 22:22:38 UTC 
When is the next release scheduled?
Comment 13 Jan F. Chadima 2011-06-13 08:32:48 UTC 
fedora 16
Comment 14 Philip Prindeville 2011-06-13 14:55:00 UTC 
(In reply to comment #13)
> fedora 16

No, I meant the next release of this package... there won't be a bugfix release for f15?
Comment 15 Jan F. Chadima 2011-06-14 06:10:07 UTC 
may be if you really need it (I think that this fix does not bring anything fundamental)
it not add extra security ... it is not a regression
it only allows another configuration file notation