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.