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

Logged in as guest

Viewing Software Bugs/6899
Full headers

From: michael@stroeder.com
Subject: Read Entry Control response value is not compliant to definition of SearchResultEntry
Compose comment
Download message
State:
0 replies:
6 followups: 1 2 3 4 5 6

Major security issue: yes  no

Notes:

Notification:


Date: Fri, 08 Apr 2011 21:39:52 +0000
From: michael@stroeder.com
To: openldap-its@OpenLDAP.org
Subject: Read Entry Control response value is not compliant to definition of SearchResultEntry
Full_Name: Michael Str.der
Version: 2.4.25
OS: 
URL: 
Submission from: (NULL) (84.163.53.138)


The very same client code was successfully tested with OpenDJ 2.4.1 but does not
work with OpenLDAP 2.4.25.

See analysis by pyasn1 developer on the pyasn1 mailing list:

--------------------------------- snip --------------------------------- 
It looks to me that your BER data does not fully match ASN.1 specification for
the SearchResultEntry object. According to RFC2251, the grammar is as follows:

        SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
             objectName      LDAPDN,
             attributes      PartialAttributeList }

...

Notice the [implicitly] tagged outer SEQUENCE. In your BER data, that additional
tag seems to be missing and default tag for SEQUENCE type is
used instead.

If you modify the original pyasn1 grammar for SearchResultEntry object to match
your BER data (but not the standard!), pyasn1 decoder succeeds.

>>> from pyasn1_modules.rfc2251 import SearchResultEntry
>>> from pyasn1.type.univ import Sequence
>>> from pyasn1.codec.ber import decoder
>>> ber = '0c\x043cn=Samba Unix UID 
Pool,ou=Testing,dc=stroeder,dc=de0,0\x14\x04\tuidNumber1\x07\x04\x05100050\x14\x04\tgidNumber1\x07\x04\x0510005'
>>> SearchResultEntry.tagSet
TagSet(Tag(tagClass=64, tagFormat=32, tagId=4))
# the following statement will invalidate SearchResultEntry grammar!
>>> SearchResultEntry.tagSet = univ.Sequence.tagSet
>>> SearchResultEntry.tagSet
TagSet(Tag(tagClass=0, tagFormat=32, tagId=16))
>>> searchResultEntry, _ =
decoder.decode(ber,asn1Spec=SearchResultEntry())
>>> print searchResultEntry.prettyPrint()
SearchResultEntry:
 objectName='cn=Samba Unix UID Pool,ou=Testing,dc=stroeder,dc=de'
 attributes=PartialAttributeList:
  Sequence:
   type='uidNumber'
   vals=SetOf:
    '10005'
  Sequence:
   type='gidNumber'
   vals=SetOf:
    '10005'
>>>

Therefore my impression is that OpenLDAP yields incorrect BER data for
SearchResultEntry object. What do you think?

Cheers,
Ilya

> I'd like to decode a LDAPv3 control value returned by OpenLDAP 2.4.25 when
> Pre-Read-Control was sent along with a LDAP modify request. But decoding
it
> does not work.
>
> Short example:
>
>>>> from pyasn1_modules.rfc2251 import SearchResultEntry
>>>> from pyasn1.codec.ber import decoder
>>>> ber = '0c\x043cn=Samba Unix UID
> Pool,ou=Testing,dc=stroeder,dc=de0,0\x14\x04\tuidNumber1\x07\x04\x05100050\x14\x04\tgidNumber1\x07\x04\x0510005'
>>>> decoder.decode(ber,asn1Spec=SearchResultEntry())
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
>  File
> "/usr/local/lib/python2.6/site-packages/pyasn1-0.0.13a-py2.6.egg/pyasn1/codec/ber/decoder.py",
> line 663, in __call__
>    '%s not in asn1Spec: %s' % (tagSet, repr(asn1Spec))
> pyasn1.error.PyAsn1Error: TagSet(Tag(tagClass=0, tagFormat=32, tagId=16))
not
> in asn1Spec: SearchResultEntry()
>>>>


Followup 1

Download message
Date: Tue, 07 Jun 2011 12:58:07 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
To: openldap-its@OpenLDAP.org
Subject: Re: (ITS#6899) Read Entry Control response value is not compliant
 to definition of SearchResultEntry
Any chance this will be fixed?

It would be very handy for sync processes to get back the entryUUID generated 
by OpenLDAP of a new entry in an AddResponse without having to read the new 
entry once more.



Followup 2

Download message
Date: Tue, 07 Jun 2011 15:32:48 +0200
From: Pierangelo Masarati <masarati@aero.polimi.it>
To: michael@stroeder.com
CC: openldap-its@OpenLDAP.org
Subject: Re: (ITS#6899) Read Entry Control response value is not compliant
 to definition of SearchResultEntry
On 06/07/2011 12:58 PM, michael@stroeder.com wrote:
> Any chance this will be fixed?
>
> It would be very handy for sync processes to get back the entryUUID
generated
> by OpenLDAP of a new entry in an AddResponse without having to read the new
> entry once more.

If I get things right, what seems to be missing is a 
LDAP_RES_SEARCH_ENTRY tag right before encoding the search entry, 
something like

diff --git a/servers/slapd/result.c b/servers/slapd/result.c
index 0803f7f..3a21fb5 100644
--- a/servers/slapd/result.c
+++ b/servers/slapd/result.c
@@ -1042,7 +1042,8 @@ slap_send_search_entry( Operation *op, SlapReply *rs )
  #endif
         if ( op->o_res_ber ) {
                 /* read back control */
-           rc = ber_printf( ber, "{O{" /*}}*/, &rs->sr_entry->e_name
);
+           rc = ber_printf( ber, "t{O{" /*}}*/,
+                       LDAP_RES_SEARCH_ENTRY, &rs->sr_entry->e_name
);
         } else {
             rc = ber_printf( ber, "{it{O{" /*}}}*/, op->o_msgid,
                         LDAP_RES_SEARCH_ENTRY, &rs->sr_entry->e_name
);

but I'd like to have some feedback.

p.



Followup 3

Download message
Date: Wed, 08 Jun 2011 09:48:07 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
To: Pierangelo Masarati <masarati@aero.polimi.it>
CC: openldap-its@OpenLDAP.org
Subject: Re: (ITS#6899) Read Entry Control response value is not compliant
 to definition of SearchResultEntry
Pierangelo Masarati wrote:
> On 06/07/2011 12:58 PM, michael@stroeder.com wrote:
>> Any chance this will be fixed?
>>
>> It would be very handy for sync processes to get back the entryUUID
generated
>> by OpenLDAP of a new entry in an AddResponse without having to read the
new
>> entry once more.
>
> If I get things right, what seems to be missing is a LDAP_RES_SEARCH_ENTRY
tag
> right before encoding the search entry, something like
 > [..patch snipped..]

Thanks!

With your patch the response control is now decoded correctly and it behaves 
as expected for all operations except Modify DN Operation:
It returns empty value lists for all attributes no matter how deleteoldrdn is 
set. The DN returned is correct.

Here's the trace log from the Python script:

----------------------------- snip -----------------------------
*** ldap://localhost:2071/ - SimpleLDAPObject.rename 
(('uid=ablume,ou=Users,ou=schulung,dc=stroeder,dc=local', 'uid=ablume2', None, 
0, [('1.3.6.1.1.13.2', True, '0\x06\x04\x01*\x04\x01+')], None),{})
=> result: 5
*** ldap://localhost:2071/ - SimpleLDAPObject.result4 ((5, 1, -1, 0, 0, 0),{})
=> result: (109, [], 5, [('1.3.6.1.1.13.2', 0, 
'd\x82\x01N\x045uid=ablume2,ou=Users,ou=schulung,dc=stroeder,dc=local0\x82\x01\x130\x07\x04\x03uid1\x000\x0f\x04\x0bobjectClass1\x000\r\x04\tuidNumber1\x000\r\x04\tgidNumber1\x000\x11\x04\rhomeDirectory1\x000\x06\x04\x02cn1\x000\x19\x04\x15structuralObjectClass1\x000\r\x04\tentryUUID1\x000\x10\x04\x0ccreatorsName1\x000\x13\x04\x0fcreateTimestamp1\x000\x0c\x04\x08entryCSN1\x000\x11\x04\rmodifiersName1\x000\x13\x04\x0fmodifyTimestamp1\x000\x0b\x04\x07entryDN1\x000\x15\x04\x11subschemaSubentry1\x000\x13\x04\x0fhasSubordinates1\x00')])
resp_ctrls[0].dn: uid=ablume2,ou=Users,ou=schulung,dc=stroeder,dc=local
resp_ctrls[0].entry:
{'cn': [],
  'createTimestamp': [],
  'creatorsName': [],
  'entryCSN': [],
  'entryDN': [],
  'entryUUID': [],
  'gidNumber': [],
  'hasSubordinates': [],
  'homeDirectory': [],
  'modifiersName': [],
  'modifyTimestamp': [],
  'objectClass': [],
  'structuralObjectClass': [],
  'subschemaSubentry': [],
  'uid': [],
  'uidNumber': []}
----------------------------- snip -----------------------------

Ciao, Michael.



Followup 4

Download message
Date: Wed, 8 Jun 2011 21:23:41 +0200 (CEST)
Subject: Re: (ITS#6899) Read Entry Control response value is not compliant 
     to definition of SearchResultEntry
From: masarati@aero.polimi.it
To: michael@stroeder.com
Cc: openldap-its@openldap.org
> Pierangelo Masarati wrote:
>> On 06/07/2011 12:58 PM, michael@stroeder.com wrote:
>>> Any chance this will be fixed?
>>>
>>> It would be very handy for sync processes to get back the entryUUID
>>> generated
>>> by OpenLDAP of a new entry in an AddResponse without having to read
the
>>> new
>>> entry once more.
>>
>> If I get things right, what seems to be missing is a
>> LDAP_RES_SEARCH_ENTRY tag
>> right before encoding the search entry, something like
>  > [..patch snipped..]
>
> Thanks!
>
> With your patch the response control is now decoded correctly and it
> behaves
> as expected for all operations except Modify DN Operation:
> It returns empty value lists for all attributes no matter how deleteoldrdn
> is
> set. The DN returned is correct.
>
> Here's the trace log from the Python script:
>
> ----------------------------- snip -----------------------------
> *** ldap://localhost:2071/ - SimpleLDAPObject.rename
> (('uid=ablume,ou=Users,ou=schulung,dc=stroeder,dc=local', 'uid=ablume2',
> None,
> 0, [('1.3.6.1.1.13.2', True, '0\x06\x04\x01*\x04\x01+')], None),{})
> => result: 5
> *** ldap://localhost:2071/ - SimpleLDAPObject.result4 ((5, 1, -1, 0, 0,
> 0),{})
> => result: (109, [], 5, [('1.3.6.1.1.13.2', 0,
> 'd\x82\x01N\x045uid=ablume2,ou=Users,ou=schulung,dc=stroeder,dc=local0\x82\x01\x130\x07\x04\x03uid1\x000\x0f\x04\x0bobjectClass1\x000\r\x04\tuidNumber1\x000\r\x04\tgidNumber1\x000\x11\x04\rhomeDirectory1\x000\x06\x04\x02cn1\x000\x19\x04\x15structuralObjectClass1\x000\r\x04\tentryUUID1\x000\x10\x04\x0ccreatorsName1\x000\x13\x04\x0fcreateTimestamp1\x000\x0c\x04\x08entryCSN1\x000\x11\x04\rmodifiersName1\x000\x13\x04\x0fmodifyTimestamp1\x000\x0b\x04\x07entryDN1\x000\x15\x04\x11subschemaSubentry1\x000\x13\x04\x0fhasSubordinates1\x00')])
> resp_ctrls[0].dn: uid=ablume2,ou=Users,ou=schulung,dc=stroeder,dc=local
> resp_ctrls[0].entry:
> {'cn': [],
>   'createTimestamp': [],
>   'creatorsName': [],
>   'entryCSN': [],
>   'entryDN': [],
>   'entryUUID': [],
>   'gidNumber': [],
>   'hasSubordinates': [],
>   'homeDirectory': [],
>   'modifiersName': [],
>   'modifyTimestamp': [],
>   'objectClass': [],
>   'structuralObjectClass': [],
>   'subschemaSubentry': [],
>   'uid': [],
>   'uidNumber': []}
> ----------------------------- snip -----------------------------

I suspect ors_attrsonly is set by mistake.  Please try this:

--- a/servers/slapd/result.c
+++ b/servers/slapd/result.c
@@ -1042,7 +1042,8 @@ slap_send_search_entry( Operation *op, SlapReply *rs )
 #endif
        if ( op->o_res_ber ) {
                /* read back control */
-           rc = ber_printf( ber, "{O{" /*}}*/, &rs->sr_entry->e_name
);
+           rc = ber_printf( ber, "t{O{" /*}}*/,
+                       LDAP_RES_SEARCH_ENTRY, &rs->sr_entry->e_name
);
        } else {
            rc = ber_printf( ber, "{it{O{" /*}}}*/, op->o_msgid,
                        LDAP_RES_SEARCH_ENTRY, &rs->sr_entry->e_name
);
@@ -1744,6 +1745,7 @@ int slap_read_controls(
        myop.o_res_ber = ber;
        myop.o_callback = NULL;
        myop.ors_slimit = 1;
+       myop.ors_attrsonly = 0;

        rc = slap_send_search_entry( &myop, rs );
        if( rc ) return rc;




Followup 5

Download message
Date: Wed, 08 Jun 2011 21:45:48 +0200
From: =?ISO-8859-15?Q?Michael_Str=F6der?= <michael@stroeder.com>
To: masarati@aero.polimi.it
CC: openldap-its@openldap.org
Subject: Re: (ITS#6899) Read Entry Control response value is not compliant
 to definition of SearchResultEntry
masarati@aero.polimi.it wrote:
>> With your patch the response control is now decoded correctly and it
>> behaves
>> as expected for all operations except Modify DN Operation:
>> It returns empty value lists for all attributes no matter how
deleteoldrdn
>> is
>> set. The DN returned is correct.
>
> I suspect ors_attrsonly is set by mistake.  Please try this:
>
> +       myop.ors_attrsonly = 0;

With your last patch everything works as expected now. Thanks a lot.

Ciao, Michael.



Followup 6

Download message
Date: Wed, 8 Jun 2011 22:21:06 +0200 (CEST)
Subject: Re: (ITS#6899) Read Entry Control response value is not compliant 
     to definition of SearchResultEntry
From: masarati@aero.polimi.it
To: michael@stroeder.com
Cc: openldap-its@openldap.org
> masarati@aero.polimi.it wrote:
>>> With your patch the response control is now decoded correctly and
it
>>> behaves
>>> as expected for all operations except Modify DN Operation:
>>> It returns empty value lists for all attributes no matter how
>>> deleteoldrdn
>>> is
>>> set. The DN returned is correct.
>>
>> I suspect ors_attrsonly is set by mistake.  Please try this:
>>
>> +       myop.ors_attrsonly = 0;
>
> With your last patch everything works as expected now. Thanks a lot.

Great.  I've committed it.  Thanks, p.


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