[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: ldapmodify crashes with long-ish input for an entry
On Sat, Jan 03 2015 at 15:39:38 +0000, Howard Chu scribbled
in "Re: ldapmodify crashes with long-ish input for an entry":
> Dameon Wagner wrote:
> > On Sat, Jan 03 2015 at 01:31:10 +0000, Howard Chu scribbled
> >> Define lengthy - how many bytes?
> >
> > For the complete LDIF of the entry update in question, it is
> > 672808 bytes (658K) -- I haven't done an exhaustive "trial and
> > error" analysis to find the boundary between OK and too-big, but
> > at 68233 bytes (67K, or 1000 lines of updates for the entry) the
> > update completes OK, but at 205105 bytes (201K or 3000 lines) the
> > update fails as described.
>
> >> That looks like a bug in Cyrus SASL. What SASL mechanism are you
> >> using?
> >
> > GSSAPI -- we use Kerberos for nearly everything, and the task in
> > question uses a credential cache created from a keytab using
> > k5start, though as an independent process (we're not using k5start
> > to run the task's commands itself).
> >
> > /etc/sasl/slapd.conf for the system in question contains only
> > "mech_list: gssapi".
> >
> > While I must admit that C isn't my forte (I'm more on the admin
> > side of sysadmin than on the development side), I'm comfortable
> > reading code and had a look through the code-base for those
> > sb_sasl* messages and didn't see anything specific enough for my
> > untrained (or unfamiliar) eye to use as a clue for further
> > sleuthing.
> >
> > While it is quite probably an incorrect assumption, I assumed at
> > the time that the messages may have been caused by the client side
> > closing or dropping the connection unexpectedly.
> >
> > If it is of any interest, I see the same issue with both
> > libsasl2-modules-gssapi-heimdal and libsasl2-modules-gssapi-mit
> > Debian packages.
>
> That's good information. Unfortunately I can't reproduce the problem
> here, ldapmodifying a group with 4640 members (237KB) works fine for
> me thru SASL.
>
> It might be enlightening to run slapd with -d2 to show the packet
> decoding activity. Also run ldapmodify with -d2.
There's quite a bit out output, which is to be expected I guess, and
comes to just over 5MB when bzip2 compressed -- would you mind if I
sent the files to you directly rather than spam the maillist with the
whole files?
The output of both ldapmodify and slapd with -d2, for a single
attempted ldapmodify update appears to have matching data on both
sides up until the list of modifications is prepared to be sent -- at
this point the ldapmodify output lists "ldap_write: want=714986,
written=714986" followed by the DN, some encoded data, and the list of
members to add (the full list from what I can tell).
On the slapd side, it reports the now familiar sasl message, and an
ldap_read error:
#---8<-----------------------------------------------------------------
sb_sasl_cyrus_decode: failed to decode packet: generic failure
sb_sasl_generic_read: failed to decode packet
ldap_read: want=8 error=Input/output error
#---8<-----------------------------------------------------------------
After that, both sides of the debug output have the same 229 bytes,
which I'm guessing is closing the connection. Slapd has nothing else
to say other than in response to me shutting down the daemon process.
On the client side, ldapmodify has little more to say other than:
#---8<-----------------------------------------------------------------
ldap_result: Can't contact LDAP server (-1)
tls_write: want=69, written=69
0000: 15 03 03 00 40 3a 27 c1 34 5c 5f ef 7e 6c c7 68 ....@:'.4\_.~l.h
0010: 92 f3 5f bc 8b a7 72 78 57 27 ed 72 9a 99 fa 6d .._...rxW'.r...m
0020: 1d 42 66 07 49 04 77 86 57 4f 06 b4 8c 28 58 7e .Bf.I.w.WO...(X~
0030: 94 f4 22 ab df 7d 8f 43 a5 3b 99 84 18 92 ca 73 .."..}.C.;.....s
0040: a4 41 f8 ab 3f .A..?
tls_write: want=277 error=Bad file descriptor
#---8<-----------------------------------------------------------------
None of the above may be useful in isolation though, requiring
additional context from the debug output to make complete sense to
someone more familiar with what's supposed to be going on.
<SNIP>
> > Since writing originally, I've had a look (with my previously
> > admitted limited C skills) to compare any differences between
> > ldapmodify for the (working) 2.4.24, the (not working) 2.4.31 and
> > the (also not working) 2.4.40. There's little change to speak of
> > from what I can see, and nothing that looked to my eye like it
> > might be the cause (though I've only really looked through
> > clients/tools/ldapmodify.c, and very briefly through
> > libraries/libldap/modify.c)
>
> I also see no relevant changes from 2.4.24 to the current RE for
> ldapmodify.c or libldap/cyrus.c (where encoding/decoding is done).
>
> If your tools are dynamically linked, you might try mixing the tools
> and libraries. E.g., try the 2.4.24 ldapmodify against the newer
> libldap. If that reproduces the bug, then we know to look closer at
> libldap.
(I meant to type 2.4.23, apologies for the typo)
I've had a brief try, but I'm getting library load errors relating to
wanting libssl.so.0.9.8, where as wheezy now has libssl.so.1.0.0, and
a couple of quick attempts to build 2.4.23 for wheezy are failing when
running the configure script with:
#---8<-----------------------------------------------------------------
checking for db.h... yes
checking for Berkeley DB major version in db.h... 5
checking for Berkeley DB minor version in db.h... 1
checking if Berkeley DB version supported by BDB/HDB backends... yes
checking for Berkeley DB link (default)... no
configure: error: BDB/HDB: BerkeleyDB not available
make: *** [configure] Error 1
#---8<-----------------------------------------------------------------
I'll have another go tomorrow though to see if I can tweak that enough
to build -- google has a few hits, but most that I've looked at so far
related to making sure libdb-dev is installed, which it is.
> > After that, I'm less sure that ldapmodify is where the problem
> > lies (rather it's just where I'm seeing it manifest).
> >
> > Thanks for your help Howard -- if you're at FlossUK again this
> > year I should remember to buy you a pint by way of thanks in
> > general (not just as a bribe for helping me out now :) and do
> > bring the violin again, it's a great way to start a presentation!
> > (Re: your talk about mdb in Edinburgh 2012)
>
> Ah I hadn't submitted a talk for FlossUK this year. Will see if I
> get sufficiently motivated to come up with one...
Should be pretty good this year as it's in York, which other than
being a lovely town is, I believe, the hometown of the main sponsors.
I missed last year (I was at CERN for the OpenAFS/Kerberos conference
the week before, which was great too), but a few colleagues went to
the OpenLDAP workshop prior to the FlossUK conference itself, and by
all accounts found it very useful.
Thanks again for all your help (on a weekend too), it really is
appreciated.
Cheers.
Dameon.
--
><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><
Dameon Wagner, Systems Development and Support Team
IT Services, University of Oxford
><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><