Need a good way to deal with 'relax' security

[Matthias Dieter Wallnöfer]

Hi Andrew,

no problem for me - I've reopened the bug report. Regarding different 
controls: I wonder if this won't make everything too complex to achieve. 
If we would like to achieve this then we should use RELAX for OpenLDAP 
and some other RELAX for our actual uses in the dsdb code.
It's much better if we start looking at the PERMISSIVE_MODIFY control - 
probably this can substitute RELAX at least in some cases.

Greets,
Matthias

Andrew Bartlett wrote:
> Matthias,
>
> I've just reverted your patch to remove the network handles for 'RELAX',
> as this breaks the OpenLDAP backend (which is the reason it had the
> network handlers in the first place).
>
> Firstly, I wish to apologise for doing so without asking you first.  I
> had it reverted for some local testing, and intended to push just a
> second patch.
>
> However, we do need to sort out a secure, but sensible way forward.
>
> The best way I can think to do that is to reinforce the changes tridge
> has made to rootDSE, which now walks over the full list of controls.
>
> I suggest that we should, as well as marking all handled controls as
> non-critical, reject here controls based on some policy about their
> being available over LDAP (in conjunction with an opaque pointer
> indicating that this is an LDAP connection, or 'security level' check on
> the connecting user).
>
> That would remove the encode/decode layer from being a stop-gap security
> barrier.
>
> (We also need to split 'relax' into multiple parts, to relax different
> things based on the caller's indication).
>
> Andrew Bartlett
>