Re: (ITS#7863) Invalid DN syntax (34) not written by slapo-accesslog

[pierangelo.masarati@polimi.it]

On 05/29/2014 06:13 PM, michael@stroeder.com wrote:
> Howard Chu wrote:
>> michael@stroeder.com wrote:
>>> It seems that modify requests which failed due to Invalid DN syntax (34) are
>>> not
>>> written to accesslog-DB. I guess that those requests get abandoned by the
>>> frontend and never reach the backend at all.
>>
>> Correct.
>>
>>> It would be handy to see the invalid modify request in the accesslog-DB though.
>>>
>>> Any chance to achieve this?
>>
>> Not likely. The frontend must call select_backend() based on the incoming DN
>> to determine which backend to invoke, and thus which stack of overlays are
>> involved. If the DN is invalid, no selection can occur.
>
> Hmm, I've done some more tests. Invalid syntax (21) also does not make it
> beyond the frontend into accesslog-DB.
>
> I have no clear opinion on this. Of course the current behaviour is good for
> performance. But sometimes one would like to observe what broken LDAP clients
> sent in a modify request in the past.
>
> Also running with BER loglevel or breaking up the TLS connection with stunnel
> and sniff with Wireshark is not always an option.
>
> Having this configurable would be great.
>
> What's your opinion on this?

In terms of code architecture, overlays have been designed to work on 
validated data (the request must be well formed).  To this end, the 
notion of "frontend" database was added to make it possible to layer an 
overlay *before* backend selection.

To have a custom piece of code muck with a request before it is 
validated (or even before it is parsed) you need to split the code into:

- parsing, without doing any sanity check

- allow custom code to step in

- do validation afterwards

This does not necessarily imply performance penalty (when no custom code 
steps in, the amount of operations would be the same for sane requests; 
in case of malformed requests, you would miss the opportunity to bail 
out on the first inconsistency).

However, it would imply significant refactorization of the current code, 
without (IMHO) a strong motivation for it: malformed requests are 
already handled in terms of response to clients, and somehow logged.

An (expensive) alternative would be to register a handler at connection 
level which duplicates the parsing to anticipate checking for errors 
that would be detected before passing control to the frontend.  Not the 
way I'd go, unless strictly necessary.

A paranoid but intriguing alternative would be to implement an operation 
mode that keeps parsing after the first error is detected, turning the 
operation into a no-op.  Again, lots of refactorization and error 
handling and so on (for example, what if a syntax, an attribute 
description or a matching rule is not found?  You'd always have to check 
that the corresponding pointer is not NULL before using it, whereas 
right now we often assume that if execution got there, data must be 
consistent.  Of course, we could introduce dummy syntaxes 
"NonExistingSyntax", ..., but we'd probably need to define their 
semantics in such a way that they apply to every case we need to handle 
and so).

My 2c.

p.

-- 
Pierangelo Masarati
Associate Professor
Dipartimento di Scienze e Tecnologie Aerospaziali
Politecnico di Milano