Re: (ITS#6545) delta-syncrepl rejects modification master accepted

[michael@stroeder.com]

ondra@mistotebe.net wrote:
> On Wed, Apr 05, 2017 at 07:32:46AM -0400, Frank Swasey wrote:
>> Thanks for the patch to provide a test script that just shows the same
>> thing.
>>
>> I see two possible solutions:
>>
>>  1) replacing the same attribute twice in the same modify LDIF is illegal
>> (as it was in older releases)
> 
> AFAIK, LDAP doesn't forbid it so I don't see that going away.

Yes, there's no text in RFC 4511 which forbids this:
https://tools.ietf.org/html/rfc4511#section-4.6

However personally I consider LDAP clients sending modify requests like this to be
broken/mis-behaving. (And I'd like to know which LDAP clients were causing this ITS.)

=> There could be a slapd per-backend configuation directive to disallow it with a strong
hint in the docs recommending to disallow it when using delta-syncrepl.

Suggestion:
disallow mod_attr_repeated

>>  2) the accesslog/syncrepl needs to record the final result, not every bit
>> of the change.
> 
> Two problems:
> - the log is meant to record the request for review/statistics purposes
>   as well and should record the intent, not just the result
> - the modification might fail, in that case you still need an accurate
>   record of the request

IIRC slapo-accesslog was primarily implemented for delta-syncrepl.

Personally I'm in the (ab)use-slapo-accesslog-as-auditlog camp. ;-)
But still I'd consider an optimized changes list written to accesslog to be perfectly
fine for security auditing because it would represent what caused the modification of the
database content.

Also note that not every failed modification is written to accesslog-DB anyway because
most malformed write operations already fail in slapd's front-end (schema check etc.) and
never reach the DB backend (and thus slapo-accesslog). So debugging errornous clients is
something for which you have to use Wireshark etc. in most cases anyway.

I'm not familiar with the inner workings of slapd but these things should be carefully
considered when optimizing the changes list of a modify request:
1. constraint checking (slapo-unique and slapo-constraint)
2. impact on indexing
3. access control, especially with val=foo part in the ACL

1. and 2. are hopefully already done on the "resulting entry after the entire list of
modifications is performed" (RFC 4511).

Ciao, Michael.