[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: dnNormalize2 failed assertion (sasl_regexp?)

* Pierangelo Masarati (ando@sys-net.it) wrote:
> The assert is there to trap situations like this.  If you don't

Yet everything seems to work fine without it, that doesn't make a whole
lot of sense to me.

> like it, compile with -DNDEBUG.  The strlen MUST work because
> all the dn handling does terminate strings with '\0', so the assert
> MUST succeed or something mucked with the DN in an erroneous manner
> (as in this case: who put the '\b' there?).  I suggest you let alone
> the asserts and try to find out who's playing with the DN strings.

I believe that something just isn't putting the NULL there, and I
suspect it may be SASL.  I havn't got a debugging version of SASL around
atm unfortunately so I'm not sure.  A backtrace looks like this though:

(gdb) bt
#0  slap_sasl_getdn (conn=0x4051f0c8, id=0x8143614 "dn:uid=sfrost,cn=SNOWMAN.NET,cn=gssapi,cn=auth\024\b\021", len=46, user_realm=0x8151088 "SNOWMAN.NET", 
    dn=0xbf3ff7c4, flags=4) at /data1/sfrost/debs/openldap21/openldap21-2.1.12/servers/slapd/sasl.c:308
#1  0x0808b643 in slap_sasl_canonicalize (sconn=0x81416f0, context=0x4051f0c8, in=0x8143614 "dn:uid=sfrost,cn=SNOWMAN.NET,cn=gssapi,cn=auth\024\b\021", 
    inlen=46, flags=2, user_realm=0x8151088 "SNOWMAN.NET", out=0x8142000 "", out_max=256, out_len=0x8141f5c)
    at /data1/sfrost/debs/openldap21/openldap21-2.1.12/servers/slapd/sasl.c:855
#2  0x400f81e7 in _sasl_canon_user () from /usr/lib/libsasl2.so.2
#3  0x403ec420 in _init () from /usr/lib/sasl2/libgssapiv2.so.2
#4  0x4010065e in sasl_server_step () from /usr/lib/libsasl2.so.2
#5  0x0808c58f in slap_sasl_bind (conn=0x4051f0c8, op=0x81425a8, dn=0xbf3ffa34, ndn=0xbf3ffa2c, cred=0xbf3ffa0c, edn=0xbf3ffa24, ssfp=0xbf3ffa04)
    at /data1/sfrost/debs/openldap21/openldap21-2.1.12/servers/slapd/sasl.c:1540
#6  0x0806c4fb in do_bind (conn=0x4051f0c8, op=0x81425a8) at /data1/sfrost/debs/openldap21/openldap21-2.1.12/servers/slapd/bind.c:299
#7  0x0805374c in connection_operation (ctx=0x81412e8, arg_v=0x81428c8) at /data1/sfrost/debs/openldap21/openldap21-2.1.12/servers/slapd/connection.c:913
#8  0x4001efb0 in ldap_int_thread_pool_wrapper (xpool=0x80eb1a8) at /data1/sfrost/debs/openldap21/openldap21-2.1.12/libraries/libldap_r/tpool.c:431
#9  0x40273d53 in pthread_start_thread () from /lib/libpthread.so.0
#10 0x40273d99 in pthread_start_thread_event () from /lib/libpthread.so.0

As you can see above, there's other junk off the end this time, and
that junk gets passed in to slap_sasl_canonicalize.  Is that the
first that ldap sees it?  Perhaps it would make sense to just force
the issue and put a \0  at the end as soon as it's seen?  Maybe I'll
find some time to build a debugging version of SASL and see if I can
figure it out.


Attachment: pgphqxHXEIbMG.pgp
Description: PGP signature