On Wed, Apr 05, 2017 at 04:14:12PM +0200, Michael Ströder wrote:

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.)

I'm not saying it's common or good practice ;)

=> 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

In my view, that's more pain than it's worth.

...

...

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.

I don't think it matters what it was written for, the fact that it's officially useful for that as you and others have realised means they might object to us making drastic changes in 2.4, a series the project have tried to freeze even maintenance for.

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 think most of the ones that don't reach accesslog get a protocol error or come from anonymous connections, schema checking and ACL should happen later.

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

4. and 2. are hopefully already done on the "resulting entry after the entire list of

modifications is performed" (RFC 4511).

Not sure I follow.

On the consumer, syncrepl bypasses all ACLs and the overlays you mention should already be capable of passing the operation intact. On the provider side it depends on the overlay order and the administrator has the option to decide that if they wish. Consistency and data model are generally maintained quite alright.