Re: (ITS#6647) Overlay sssvlv is always loaded

[masarati@aero.polimi.it]

> 2010/9/14  <masarati@aero.polimi.it>:
>>> On 14/09/2010 11:33, clem.oudot@gmail.com wrote:
>>>> Full_Name: Clement OUDOT
>>>> Version: 2.4.23
>>>> OS: GNU/Linux
>>>> URL: ftp://ftp.openldap.org/incoming/
>>>> Submission from: (NULL) (83.145.72.122)
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I am using OpenLDAP 2.4.23 compiled with --enable-overlays (RPMs from
>>>> http://www.ltb-project.org). Overlays are not compiled as modules.
>>>>
>>>> Overlay sssvlv is compiled, but not activated in configuration
>>>>
>>>> But:
>>>> * SSS and VLV controls are displayed in RootDSE
>>>> * SSS control is taken into account if present in an LDAP search
>>>> operation
>>>>
>>>> For example, a search with SSS control on cn (which has no ordering
>>>> rule)
>>>> gives:
>>>> result: 18 Inappropriate matching
>>>> text: serverSort control: No ordering rule
>>>>
>>>>
>>>> The error would be normal if overlay has been activated, but I think
>>>> control
>>>> should be ignored if overlay is not active.
>>>
>>> I hit this exact same issue just last week - it seems that when the
>>> overlay is compiled in, the SSS control is displayed in the rootDSE.
>>>
>>> In my case, this caused a client to attempt to use the control, then
>>> fail with a similar message as above. Without the overlay compiled in,
>>> the client just doesn't use the control, and the client's operation
>>> suceeded.
>>>
>>> My point is that I agree this probably shouldn't be activated by
>>> default, or at the very least a clear warning added in the
>>> documentation=
> .
>>
>> This behavior is common to all overlays that register a general feature,
>> like controls, extended ops or even just a bit of custom schema: the
>> registration is done when the module is loaded (or at startup, if the
>> module is statically built into slapd). =A0As a consequence, the feature
>> =
> is
>> advertised because slapd knows about it, but since it is not explicitly
>> configured, does not know how to handle it.
>>
>> In the end, slapd's behavior is correct: it recognizes the feature, it
>> recognizes requests for the feature, but does not know how to handle
>> them=
> ,
>> thus returns an appropriate error. =A0This looks pretty consistent with
>> RFC4511 and specifications of each feature, although I understand it
>> coul=
> d
>> be disappointing.
>>
>> Perhaps we could modify this behavior so that the module initialization
>> does nothing or so, and only the first instantiation of the feature
>> cause=
> s
>> the real initialization. =A0This was discussed in the past, and I recall
>> =
> it
>> created trouble when part of the initialization was needed earlier (e.g.
>> registering schema items that need to be used later in the configuration
>> or so; a clear case was back-monitor, which registers schema items that
>> are needed by other backends when registering custom monitoring; if
>> back-monitor startup didn't occur early enough, one had to instantiate
>> it
>> before any database that wanted to register custom monitoring).
>>
>> In conclusion: the current behavior is consistent; on a case by case
>> basis, feature instantiation could perhaps be deferred as much as
>> possible, unless this conflicts with other features.
>>
>
> I understand your point of view. Indeed, recompiling OpenLDAP without
> sssvlv overlay works.
>
> The fact is that for people compiling OpenLDAP with --enable-overlays,
> we have a 'regression' with overlay sssvlv, because LDAP clients are
> now using the control and get errors.
>
> Maybe the issue can be retargeted to sssvlv overlay: if an LDAP client
> is using the SSS control in a non-critical mode, OpenLDAP should
> return search results (unsorted) even if the control fails (because of
> missing ordering rule for requested attribute). If the control is
> critical, then the error must be returned.

Please try this (nearly blind) patch

<ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-14-sssvlv.1.patch>

and report through the ITS.  Thanks, p.