[Date Prev][Date Next]
Re: (ITS#4816) slurpd generates invalid ldapadd/modify requests
>> 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
Gaël Roualland -+- firstname.lastname@example.org