Re: (ITS#4816) slurpd generates invalid ldapadd/modify requests

[gael.roualland@oleane.net]

Hello,

>> Slurpd has a bug when replicating, in the way it generates the LDAPMod array of
>> the add and modify operations : if the same attribute is present several times
>> (for add) or in multiple change blocks (for modify) in the replication log, it
>> simply adds all occurences to the LDAPMod array, hence having one or more
>> attributes repeated serveral times which violates the protocol.
>> [...]
> As far as I can see, slurpd merely processes the changes in the replog. If it 
> is generating requests out of sequence, then they must have been recorded 
> out-of-sequence in the log. And yet I don't see any reason why slapd would 
> generate the modifications out of sequence.

That's right for changetype=modify, since the original code aggregates
multiple values of the same attributes in a signle LDAPmod if they're
given in order in the replog file.
But it doesn't do that for changetype=add, which toggled the bug. I
choosed to use the same code path for both for simplicity when fixing add.

> What are the circumstances that cause these improper sequences to get into 
> the replog in the first place?

In our case, it was just "add" that was problematic. Although I could
imagine the replog to be generated by something else than slapd, and I'd
expect slurpd to be able to process it as long as it is valid ldif ?

> As for copying the code from ldapmodify.c into slurpd - probably the better 
> solution would be to move the relevant code from ldapmodify.c into a library. 

Well, the relevant code is about 20 lines long, and adapted to the way
slurpd handles memory. But sure, that could be shared.

For the record, the patch I uploaded has an issue with empty changes
blocks, so I uploaded a fixed version as
ftp://ftp.openldap.org/incoming/gael.roualland-070129.diff

-- 
Gaël Roualland -+- gael.roualland@oleane.net