Re: Slapd Crashes on Asertion Failed

[Erik Persson <erik@roxen.com>]

On Mon, 3 Dec 2001, Pierangelo Masarati wrote:

> > > well, the fix is very easy: bail out everytime garbage comes in;
> > > however, I think it's better to stop the garbage at the door rather
> > > than when it's already in.  I couldn't reproduce the problem with any
> > > of the tools/library calls, so the problem should be with YOUR client.
> > > You were expected to provide a complete dump of the BER code that
> > > caused the crash, I suppose.  That would really help.
> >
> > I was using Perl's Net::LDAP, so I doubt the problem was there.  Now the
> > same problem is with PHP, so again, I'm doubtful.
> >
> > I talked to Kurt about this, and I've already sent him dumps, and I believe
> > we got down to a BER dump eventually (what is "BER" anyway?).  He said the
> > assert() is there to prevent flaws in openldap's logic, so there's obviously
> > something wrong somewhere...
>
> The BER dump means a dump of what (BER encoded) is sent over the wire.
> BER is Basic Encoding Rules, the format in which information is exchanged
> by LDAP (and other protocols, I suppose).  You should sniff what the
> client is sending to the server when it crashes (or add some extra
> debug code that dumps ALL the stuff that's coming in in hex).
>
> The point, I guess, is that a "modify" with NULL values is in fact
> a "delete".  If you try to ldapmodify an entry with
>
> dn: <some dn>
> changetype: modify
> replace: <some attr>
> -
>
> with the ldapmodify tool that comes with OpenLDAP, everything works fine,
> i.e. the attr is deleted, and if it does not exist, it is not created.
> If you can point out the differences between this message an the one that
> originates from PERL or PHP, we can try to find where the decoding
> part of slapd leaks or misinterprets the message (assuming the problem
> is there).

This might or might not be interesting:

Just today I ran into the problem with this very assert call. After having
ran around in circles i found out what had happened in my case.

I use LDAP to store users and groups and had imported my Unix group data
into posixGroup objects. My import script appearently succeded in storing
"" in userPassword attributes where there was no password in the group
file. I guess that when asked for these entries, the ldbm layer (?)
returns string terminator (NULL) and the schema checker gets an assert.

I guess that the real interesting question here is what the LDAP server
really should do when the client tries something like this? Return "object
class violation"? Something else? If the data is illegal (who said
garbage?) the server should refuse it, shouldn't it?

/Erik

-- 
Erik Persson, System Manager            <erik@roxen.com>
Roxen Internet Software                 Voice:  +46 13 376817