Bug 921167

Summary: update-policy with match type 'zonesub' crashes BIND with bind-dyndb-ldap
Product: Red Hat Enterprise Linux 6 Reporter: Najmuddin Chirammal <nc>
Component: bind-dyndb-ldapAssignee: Petr Spacek <pspacek>
Status: CLOSED ERRATA QA Contact: Namita Soman <nsoman>
Severity: high Docs Contact:
Priority: high    
Version: 6.3CC: dpal, pspacek, sradvan, yjog
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Cause: The bind-dyndb-ldap plug-in processed update policies with match-type 'zonesub' incorrectly. Consequence: The problem led to the BIND daemon terminating unexpectedly during update-policy processing. Fix: The bind-dyndb-ldap plug-in has been fixed to process update-policy with match-type 'zonesub' correctly. Result: The bind-dyndb-ldap plug-in no longer crashes during update-policy processing.
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-21 12:10:48 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 835616, 883504, 960054    

Comment 3 Petr Spacek 2013-03-13 19:07:32 UTC
Public description:

User wants to update DNS records from his DHCP server using TSIG keys, the key is added into named.conf file. Once the update-policy in LDAP is updated to use the key from named.conf named fails to start (crashes with an assertion failure).

Version-Release number of selected component (if applicable):
bind-dyndb-ldap-2.3-2.el6.x86_64

How reproducible:
Always.

Steps to Reproduce:
1.Add a key to named.conf.
for eg: 

key selfupdate {
        algorithm hmac-md5;
        secret "05Fu1ACKv1/1Ag==";
};

2. Add the key to IPA managed zone's update-policy.
for eg: 

# ipa dnszone-mod example.com --update-policy="grant EXAMPLE.COM krb5-self * A; grant EXAMPLE.COM krb5-self * AAAA; grant EXAMPLE.COM krb5-self * SSHFP; grant selfupdate zonesub A;"

(Only the last grant statement is relevant here, rest are present by default).

3. restart 'named' service.
  
Actual results: named crashes with assertion failure

named[19050]: managed-keys-zone ./IN: loaded serial 0
named[19050]: running
named[19050]: acl.c:234: INSIST(0) failed, back trace
named[19050]: #0 0x7f201cb3beff in ??
named[19050]: #1 0x7f201b4ec89a in ??
named[19050]: #2 0x7f201619d6d8 in ??
named[19050]: #3 0x7f20161a7423 in ??
named[19050]: #4 0x7f20161aa8a5 in ??
named[19050]: #5 0x7f201b50b2f8 in ??
named[19050]: #6 0x7f201aec0851 in ??
named[19050]: #7 0x7f201a42290d in ??
named[19050]: exiting (due to assertion failure)

Expected results: named start without any errors and we should be able to use the key from a client to update the zone entries.

Additional info: stack trace from the core file.

Thread 1 (Thread 0x7f7700519700 (LWP 9768)):
#0  0x00007f7701abb8a5 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007f7701abd085 in abort () at abort.c:92
#2  0x00007f7704283e14 in assertion_failed (file=<value optimized out>, line=<value optimized out>, type=<value optimized out>, cond=<value optimized out>) at ./main.c:219
#3  0x00007f7702c3a89a in isc_assertion_failed (file=<value optimized out>, line=<value optimized out>, type=<value optimized out>, cond=<value optimized out>) at assertions.c:57
#4  0x00007f76fd8f8aa8 in get_match_type (policy_str=<value optimized out>, zone=0x7f76f832beb0) at acl.c:234
#5  acl_configure_zone_ssutable (policy_str=<value optimized out>, zone=0x7f76f832beb0) at acl.c:417
#6  0x00007f76fd901331 in ldap_parse_zoneentry (entry=0x7f77042066a0, inst=0x7f7704226f10) at ldap_helper.c:1022
#7  0x00007f76fd901bcd in refresh_zones_from_ldap (ldap_inst=0x7f7704226f10) at ldap_helper.c:1161
#8  0x00007f76fd906214 in manager_create_db_instance (mctx=0x7f7705eb6250, name=<value optimized out>, argv=<value optimized out>, dyndb_args=<value optimized out>)
    at zone_manager.c:183
#9  0x00007f76fd8fac19 in dynamic_driver_init (mctx=0x7f7705eb6250, name=0x7f77042161f0 "ipa", argv=0x7f77041ff330, dyndb_args=0x7f7704202550) at ldap_driver.c:1329
#10 0x00007f7703ae2de6 in dns_dynamic_db_load (libname=<value optimized out>, name=0x7f77042161f0 "ipa", mctx=0x7f7705eb6250, argv=0x7f77041ff330, dyndb_args=0x7f7704202550)
    at ./dynamic_db.c:232
#11 0x00007f77042a24dc in configure_dynamic_db (view=0x7f76f8111550, config=<value optimized out>, vconfig=<value optimized out>, cachelist=0x7f77042161f0, bindkeys=0x7f77042161f8, 
    mctx=0x7f7705eb6250, actx=0x7f7704202090, need_hints=isc_boolean_true) at server.c:1210
#12 configure_view (view=0x7f76f8111550, config=<value optimized out>, vconfig=<value optimized out>, cachelist=0x7f77042161f0, bindkeys=0x7f77042161f8, mctx=0x7f7705eb6250, 
    actx=0x7f7704202090, need_hints=isc_boolean_true) at server.c:2784
#13 0x00007f77042a57b5 in load_configuration (filename=0x7f7700518850 "\370\005#\004w\177", server=0x7f770420d010, first_time=isc_boolean_true) at server.c:4912
#14 0x00007f77042a6bb5 in run_server (task=<value optimized out>, event=0x0) at server.c:5381
#15 0x00007f7702c592f8 in dispatch (uap=0x7f7704204010) at task.c:1012
#16 run (uap=0x7f7704204010) at task.c:1157
#17 0x00007f770260e851 in start_thread (arg=0x7f7700519700) at pthread_create.c:301
#18 0x00007f7701b7111d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115

Comment 4 Petr Spacek 2013-03-13 19:14:49 UTC
Upstream ticket:
https://fedorahosted.org/bind-dyndb-ldap/ticket/111

Comment 5 Petr Spacek 2013-03-13 19:30:32 UTC
Match type 'zonesub' is not handled properly.

Workaround:
Replace 'zonesub' with 'subdomain' match type. E.g. for zone 'example.com' use following update policy:
grant keyname subdomain example.com;

Result:
Update requests signed by key 'keyname' are allowed to change all records in zone 'example.com'.

Comment 6 Petr Spacek 2013-03-25 15:40:38 UTC
Fixed in upstream by commit 55b623b947b8bef1eb31ad6cd4efe1b846c036c4.

Comment 14 Namita Soman 2013-08-28 18:55:25 UTC
Using ipa-server-3.0.0-33.el6.x86_64, followed steps:

# cat /etc/named.conf
<snip>
...
key selfupdate {
        algorithm hmac-md5;
        secret "05Fu1ACKv1/1Ag==";
};

# ipa dnszone-mod testrelm.com --update-policy="grant TESTRELM.COM krb5-self * A; grant TESTRELM.COM krb5-self * AAAA; grant TESTRELM.COM krb5-self * SSHFP; grant selfupdate zonesub A;"
  Zone name: testrelm.com
  Authoritative nameserver: mgmt6.testrelm.com.
  Administrator e-mail address: hostmaster.testrelm.com.
  SOA serial: 1377713531
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  BIND update policy: grant TESTRELM.COM krb5-self * A; grant TESTRELM.COM krb5-self * AAAA; grant TESTRELM.COM krb5-self *
                      SSHFP; grant selfupdate zonesub A;
  Active zone: TRUE
  Allow query: any;
  Allow transfer: none;



# service named restart
Stopping named: .[  OK  ]
Starting named: [  OK  ]


# ipa dnszone-show testrelm.com --all
  dn: idnsname=testrelm.com,cn=dns,dc=testrelm,dc=com
  Zone name: testrelm.com
  Authoritative nameserver: mgmt6.testrelm.com.
  Administrator e-mail address: hostmaster.testrelm.com.
  SOA serial: 1377715681
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  BIND update policy: grant TESTRELM.COM krb5-self * A; grant TESTRELM.COM krb5-self * AAAA; grant TESTRELM.COM krb5-self *
                      SSHFP; grant selfupdate zonesub A;
  Active zone: TRUE
  Dynamic update: TRUE
  Allow query: any;
  Allow transfer: none;
  nsrecord: mgmt6.testrelm.com.
  objectclass: top, idnsrecord, idnszone


named restarted successfuly

Comment 15 Namita Soman 2013-09-04 12:18:55 UTC
Verified further. After the above steps, did further verification:
# cat dnsupdate.txt
server ipaqa64vme.testrelm.com
zone testrelm.com
key selfupdate 05Fu1ACKv1/1Ag==
update add foo.testrelm.com. 60 IN A <IPADDR>
send

# nsupdate -v -D dnsupdate.txt

Verified "Outgoing" and "Reply" results (similar to dig output). Since the update wad successful, got NOERROR.

Comment 16 errata-xmlrpc 2013-11-21 12:10:48 UTC
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-1636.html