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

[ondra@mistotebe.net]

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

-- 
OndÅ?ej Kuzník
Senior Software Engineer
Symas Corporation                       http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP