+++ This bug was initially created as a clone of Bug #625621 +++ Description of problem: s-c-bind crashes with a "string index out of range" error if a zone file has a full 8 field IPv6 address in a zone file. Version-Release number of selected component (if applicable): system-config-bind-4.0.3-4.el5 bind-9.3.6-4.P1.el5_4.2 How reproducible: every time Steps to Reproduce: 1. yum install bind bind-chroot system-config-bind 2. system-config-bind Let it create initial default zone files, then save and quit. 3. cat >>/var/named/chroot/var/named/localdomain.zone <<EOF foo IN AAAA 1111:2222:3333:4444:5555:6666:7777:8888 EOF 4. system-config-bind Actual results: Traceback (most recent call last): File "/usr/sbin/system-config-bind", line 202, in ? GUI(sys.argv) File "/usr/sbin/system-config-bind", line 91, in __init__ self.bind=BIND(self, argv) File "/usr/share/system-config-bind/BIND.py", line 96, in __init__ self.load() File "/usr/share/system-config-bind/BIND.py", line 193, in load self.zoneTree = ZoneTree(self) File "/usr/share/system-config-bind/ZoneTree.py", line 1061, in __init__ s.load() File "/usr/share/system-config-bind/ZoneTree.py", line 1088, in load s.add_zone(origin, zone) File "/usr/share/system-config-bind/ZoneTree.py", line 1226, in add_zone s.add_record(z,r) File "/usr/share/system-config-bind/ZoneTree.py", line 1256, in add_record v = r[mapping].label() File "/usr/share/system-config-bind/DNS.py", line 20, in label return this.__str__() File "/usr/share/system-config-bind/IPV6.py", line 423, in __str__ return str(self.address) File "/usr/share/system-config-bind/IPV6.py", line 402, in __str__ return self.hex_out() File "/usr/share/system-config-bind/IPV6.py", line 235, in hex_out if(output[-1] == ':'): IndexError: string index out of range Expected results: no crash Additional info: If you edit localdomain.zone and remove a field, e.g. remove the "4444" foo IN AAAA 1111:2222:3333::5555:6666:7777:8888 then s-c-bind starts correctly.
Enabling debugging with the SCB_DEBUG=FRAME environment variable shows this with the 4444 removed (i.e., when it works correctly): # SCB_DEBUG=FRAME system-config-bind ... IPV6.py:171 (hex_out): hex_out: 11112222333300005555666677778888 IPV6.py:171 (hex_out): hex_out: initial zseq: [[12, 16]] IPV6.py:171 (hex_out): hex_out: longest: 0 IPV6.py:171 (hex_out): hex_out: start: 12 end: 16 IPV6.py:171 (hex_out): hex_out: output 1: 1111:2222:3333::5555:6666:7777:8888: IPV6.py:171 (hex_out): hex_out: trailing zeros? : 8888 ... If we add the 4444 back in, the initial zseq is empty as is everything else: # SCB_DEBUG=FRAME system-config-bind ... IPV6.py:171 (hex_out): hex_out: 11112222333344445555666677778888 IPV6.py:171 (hex_out): hex_out: initial zseq: [] IPV6.py:171 (hex_out): hex_out: longest: None IPV6.py:171 (hex_out): hex_out: start: None end: None IPV6.py:171 (hex_out): hex_out: output 1: Traceback (most recent call last): ...
zseq must be "zero sequence". The code is expecting at least one field of 0s in the address. Indeed, if I change the zone file to specify a single 0 instead of the 4s, s-c-bind works okay: foo IN AAAA 1111:2222:3333:0:5555:6666:7777:8888 The code seems to be incorrectly assuming that all IPv6 addresses will have a zero sequence somewhere.
Created attachment 473569 [details] patch to handle IPv6 addresses without a zero-sequence This patch fixes the problem for me.
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux release for currently deployed products. This request is not yet committed for inclusion in a release.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-0037.html