(ITS#7687) slapd with chaining dies on ManageDsaIT control

[ck@cksoft.de]

Full_Name: Christian Kratzer
Version: 2.4.36
OS: CentOS / RedHat Enterprise
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (2003:41:c010:8001:9028:d44e:e3ea:c880)


Hi,

we have a java application using JNDI that uses the password modify extended
operation to change user passwords.

This runs fine against our masters but causes an assert when run against our
slaves that use chaining to pass the modify request to the masters.

  slapd: chain.c:199: chaining_control_remove: Assertion `op->o_ctrls != ((void
*)0)' failed.

Backtrace is as follows:

  Core was generated by `/usr/local/sbin/slapd -h ldap://:389/ ldaps://:636/ -d
1 -F /usr/local/etc/open'.
  Program terminated with signal 6, Aborted.
  #0  0x00007fdf5125c8a5 in raise () from /lib64/libc.so.6
  Missing separate debuginfos, use: debuginfo-install
openldap-release-2.4.36-1.el6.x86_64
  (gdb) bt
  #0  0x00007fdf5125c8a5 in raise () from /lib64/libc.so.6
  #1  0x00007fdf5125e085 in abort () from /lib64/libc.so.6
  #2  0x00007fdf51255a1e in __assert_fail_base () from /lib64/libc.so.6
  #3  0x00007fdf51255ae0 in __assert_fail () from /lib64/libc.so.6
  #4  0x00007fdf4e7fd3ca in chaining_control_remove (op=0x7fdef81add00,
oldctrlsp=0x7fdf07ffe078) at chain.c:199
  #5  0x00007fdf4e7feedd in ldap_chain_op (op=0x7fdef81add00, rs=0x7fdf07ffe950,
op_f=0x7fdf4e7fc680 <ldap_back_extended>,
      ref=0x7fdef81ae0c0, depth=0) at chain.c:655
  #6  0x00007fdf4e7ffd37 in ldap_chain_response (op=0x7fdef81add00,
rs=0x7fdf07ffe950) at chain.c:1092
  #7  0x00000000004954d8 in ?? ()
  #8  0x000000000043d2ee in ?? ()
  #9  0x000000000043de49 in ?? ()
  #10 0x000000000043e5ae in slap_send_ldap_extended ()
  #11 0x000000000045defc in fe_extended ()
  #12 0x00000000004957e7 in overlay_op_walk ()
  #13 0x00000000004961c7 in ?? ()
  #14 0x000000000045e315 in do_extended ()
  #15 0x000000000042df79 in ?? ()
  #16 0x000000000042e755 in ?? ()
  #17 0x00007fdf52a6d498 in ldap_int_thread_pool_wrapper (xpool=0x13f1450) at
tpool.c:688
  #18 0x00007fdf515c4851 in start_thread () from /lib64/libpthread.so.0
  #19 0x00007fdf5131290d in clone () from /lib64/libc.so.6
  (gdb)

When running slapd with heavy logging we save the only difference to ldappasswd
which works fine against our masters is that JNDI sets the ManageDsaIT by
default.

We were subsequently able to work around the issue by changing the default JNDI
behaviour so as not to set the ManageDSA IT control with:

   env.put(Context.REFERRAL, "throw");

As detailed in following related post and jndi documentation:

   http://www.openldap.org/lists/ietf-ldapext/200409/msg00035.html
   http://docs.oracle.com/javase/1.4.2/docs/guide/jndi/jndi-ldap-gl.html#referral

It would of course be helpfull if slapd would handle the situation slightly more
gracefully.  Even though the control is utterly useless in our case with
chaining it is the default on jndi so handling this case would be helpfull to
all java users out there.

I am not quire sure where this goes wrong exactly.

If anybody can write up a patch I would be more than gratefull to test as we
have a reproducible test setup on hand in our lab that we can run any time.

I can also retest with fuller debug symbols than above if required. Seems only
our modules hat debuginfo at the time of the backtrace.

Greetings
Christian Kratzer
CK Software GmbH