OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Software Bugs/6647
Full headers

From: clem.oudot@gmail.com
Subject: Overlay sssvlv is always loaded
Compose comment
Download message
State:
0 replies:
6 followups: 1 2 3 4 5 6

Major security issue: yes  no

Notes:

Notification:


Date: Tue, 14 Sep 2010 09:33:26 +0000
From: clem.oudot@gmail.com
To: openldap-its@OpenLDAP.org
Subject: Overlay sssvlv is always loaded
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.

Followup 1

Download message
Date: Tue, 14 Sep 2010 14:09:46 +0200
From: Jonathan CLARKE <jonathan.clarke@normation.com>
To: clem.oudot@gmail.com
CC: openldap-its@openldap.org
Subject: Re: (ITS#6647) Overlay sssvlv is always loaded
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.

Jonathan
-- 
==========================================
Jonathan CLARKE
------------------------------------------
Normation
44 rue Cauchy, 94110 Arcueil, France
------------------------------------------
Telephone:  +33 (0)1 83 62 26 96
------------------------------------------
Web:        http://www.normation.com/
==========================================



Followup 2

Download message
Date: Tue, 14 Sep 2010 15:54:47 +0200 (CEST)
Subject: Re: (ITS#6647) Overlay sssvlv is always loaded
From: masarati@aero.polimi.it
To: jonathan.clarke@normation.com
Cc: openldap-its@openldap.org
> 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).  As 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.  This looks pretty consistent with
RFC4511 and specifications of each feature, although I understand it could
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 causes
the real initialization.  This 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.

p.



Followup 3

Download message
Date: Tue, 14 Sep 2010 16:49:10 +0200
Subject: Re: (ITS#6647) Overlay sssvlv is always loaded
From: =?ISO-8859-1?Q?Cl=E9ment_OUDOT?= <clem.oudot@gmail.com>
To: masarati@aero.polimi.it
Cc: openldap-its@openldap.org
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.

What is your opinion?

Cl=E9ment.



Followup 4

Download message
Date: Tue, 14 Sep 2010 18:15:21 +0200 (CEST)
Subject: Re: (ITS#6647) Overlay sssvlv is always loaded
From: masarati@aero.polimi.it
To: clem.oudot@gmail.com
Cc: openldap-its@openldap.org
> 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.




Followup 5

Download message
Date: Tue, 14 Sep 2010 18:48:06 +0200 (CEST)
Subject: Re: (ITS#6647) Overlay sssvlv is always loaded
From: masarati@aero.polimi.it
To: clem.oudot@gmail.com
Cc: openldap-its@openldap.org
> 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.

I note that I have messed things up a bit in cleanup; however, this should
not affect the testing of the functionality, except if you delete the
overlay from the configuration using back-config.  If the patch works
fine, I'll fix that part.

p.



Followup 6

Download message
From: =?ISO-8859-1?Q?Cl=E9ment?= OUDOT <clem.oudot@gmail.com>
To: masarati@aero.polimi.it, openldap-its@openldap.org
Subject: Re: (ITS#6647) Overlay sssvlv is always loaded
Date: Tue, 05 Oct 2010 11:39:49 +0200
--=-sj86jeXTHEFBrrKIl07g
Content-Type: text/plain; charset=utf-8
Content-ID: <1286271588.1952.3.camel@Nokia-N900-51-1>
Content-Transfer-Encoding: 8bit

----- Message d'origine -----
> 
> > 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.
> 
> I note that I have messed things up a bit in cleanup; however, this
> should not affect the testing of the functionality, except if you delete
> the overlay from the configuration using back-config...  If the patch works
> fine, I'll fix that part.
> 


Hi,

sorry for this late reply. I tried the patch on 2.4.23 source code, the second
hunk was not working, so I deleted it to apply the patch. I am not using
cn=config anyway.

After recompiling with your patch and --enable-overlays, all works fine: a
search with sss extention returns success (and fails if the control is
critical).

So I think you can commit the code!

Thanks,

Cl..ment.
--=-sj86jeXTHEFBrrKIl07g
Content-Type: text/html; charset=utf-8
Content-ID: <1286271588.1952.5.camel@Nokia-N900-51-1>
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html><head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    <meta name="generator" content="Osso Notes">
    <title></title></head>
<body>
<p>----- Message d'origine -----
<br>&gt; 
<br>&gt; &gt; Please try this (nearly blind) patch
<br>&gt; &gt; 
<br>&gt; &gt; &lt;<a
href="ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-14-sssvlv.1.patch&gt">ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-14-sssvlv.1.patch&gt</a>;
<br>&gt; &gt; 
<br>&gt; &gt; and report through the ITS.&nbsp;
&#32;Thanks, p.
<br>&gt; 
<br>&gt; I note that I have messed things up a bit in cleanup;
however, this
<br>&gt; should not affect the testing of the functionality, except if
you delete
<br>&gt; the overlay from the configuration using
back-config.&nbsp; &#32;If the patch works
<br>&gt; fine, I'll fix that part.
<br>&gt; 
<br>
<br>
<br>Hi,
<br>
<br>sorry for this late reply. I tried the patch on 2.4.23 source code,
the second hunk was not working, so I deleted it to apply the patch. I am not
using cn=config anyway.
<br>
<br>After recompiling with your patch and --enable-overlays, all works
fine: a search with sss extention returns success (and fails if the control is
critical).
<br>
<br>So I think you can commit the code!
<br>
<br>Thanks,
<br>
<br>Cl..ment.</p>
</body>
</html>

--=-sj86jeXTHEFBrrKIl07g--


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org