Viewing Contrib/2113
Full headers

Major security issue: yes  no

Notes:
not updated obsoleted by ITS#6630
Notification:

Date: Wed, 25 Sep 2002 18:38:05 GMT
From: jenarusa@us.ibm.com
To: openldap-its@OpenLDAP.org
Subject: Duplicate Entry Control Patch

Full_Name: Julius Enarusai
Version: HEAD
OS: Linux
URL: ftp://ftp.openldap.org/incoming/dupent_patch.tar
Submission from: (NULL) (129.42.208.144)


This patch provides support for revision 8 of the "LDAP Control for a 
Duplicate Entry Representation of Search Results" Internet Draft. There
are some aspects of the ID that are not currently supported, since the ID
itself
is still being reviewed. However, the patch provides support for basic aspects
of the ID. Therefore, all comments will be appreciated.

Reply 1

From: Pierangelo Masarati <openldap-its@OpenLDAP.org>
To: jenarusa@us.ibm.com
Subject: Re: Duplicate Entry Control Patch (ITS#2113)
Date: Thu Nov 21 15:35:56 2002

> This patch provides support for revision 8 of the "LDAP Control for a 
> Duplicate Entry Representation of Search Results" Internet Draft. There
> are some aspects of the ID that are not currently supported, since the ID
> itself
> is still being reviewed. However, the patch provides support for basic
aspects
> of the ID. Therefore, all comments will be appreciated.

The patch looks fine; however its behavior has some quirks I'd like 
to investigate.

- as appears from your search.out example, after returning duplicate 
entries for each value of the dupent attr, a final entry with the 
first value and all the other requested attrs is returned.  I didn't
read draft-ietf-ldapext-ldapv3-dupent-08.txt too carefully; is it
intended?

- unfortunately your patch doesn't work quite well vith very recent
HEAD code, and significantly together with the recently committed
pagedResults control, resulting in more than page size entries being
returned and in an endless loop.  I'm afraid you'll need to dig a bit
in the server side part of the code to work it out.

Since I had to apply a few fixes to be able to patch the current HEAD
code, I'm sending you my own patch to help convergence to a committable 
version of the work.

http://www.sys-net.it/~ando/Download/Pierangelo-Masarati-20021121-Julius-Enarusa-dupent.patch

I did not include the file dupent_ctrl.c since I did not touch it;
however, I note that the functions defined there are also appended 
to libraries/libldap/controls.c and #ifdef'd out; I think this 
solution may be preferable as the number of control related functions
is not that large (yet).

Thanks indeed for the submission.

Pierangelo.

Followup 1

Subject: Re: Duplicate Entry Control Patch (ITS#2113)
To: Pierangelo Masarati <openldap-its@OpenLDAP.org>
From: "Julius Enarusai" <jenarusa@us.ibm.com>
Date: Fri, 22 Nov 2002 11:53:06 -0500

Pierangelo,

First of all, thanks for reviewing the patch. I will incorporate your patch
with the current HEAD code and re-submit soon.


>The patch looks fine; however its behavior has some quirks I'd like
>to investigate.
>
>- as appears from your search.out example, after returning duplicate
>entries for each value of the dupent attr, a final entry with the
>first value and all the other requested attrs is returned.  I didn't
>read draft-ietf-ldapext-ldapv3-dupent-08.txt too carefully; is it
>intended?

I've just reviewed the search.out file and there seems to be an error. The
draft states that all duplicated entries should be sent as separate entries
with a DuplicateSearchResult control. However, in the search.out file,
"member:cn=Manager,o=University of Michigan,c=US" should not have been
included in the non-duplicated list, since it has been sent already as a
duplicated entry. I will fix that before re-submitting.

Thanks

Julius

Followup 2

Date: Fri, 22 Nov 2002 18:17:48 +0100 (CET)
Subject: Re: Duplicate Entry Control Patch (ITS#2113)
From: "Pierangelo Masarati" <ando@sys-net.it>
To: <jenarusa@us.ibm.com>
Cc: <openldap-its@OpenLDAP.org>

>
> Pierangelo,
>
> First of all, thanks for reviewing the patch. I will incorporate your
> patch with the current HEAD code and re-submit soon.

I suggest you enable the paged result stuff (I think it's enabled
by default in current HEAD, the appropriate macro is in include/ldap.h)

This stuff creates a sort of chicken-and-egg problem with your stuff,
because the paging must stay in the backend to be able to resume from
the point where the last page stopped; however, if you dup an entry
after page-counting, you break the page counting.  I know it's shooting
in one's foot to use the two controls simultaneously; we might well
come out with refusing to accept them in the same request, but
I'd like you to consider the problem.  After all paging is standard
track, while dupent is still draft ...

>
>>The patch looks fine; however its behavior has some quirks I'd like to
>> investigate.
>>
>>- as appears from your search.out example, after returning duplicate
>> entries for each value of the dupent attr, a final entry with the first
>> value and all the other requested attrs is returned.  I didn't read
>> draft-ietf-ldapext-ldapv3-dupent-08.txt too carefully; is it intended?
>
> I've just reviewed the search.out file and there seems to be an error.
> The draft states that all duplicated entries should be sent as separate
> entries with a DuplicateSearchResult control. However, in the search.out
> file, "member:cn=Manager,o=University of Michigan,c=US" should not have
> been included in the non-duplicated list, since it has been sent already
> as a duplicated entry. I will fix that before re-submitting.

Looking forward to seeing the new version :)

Pierangelo.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it

Followup 3

Subject: Re: Duplicate Entry Control Patch (ITS#2113)
To: ando@sys-net.it
Cc: <openldap-its@OpenLDAP.org>
From: Julius Enarusai <jenarusa@us.ibm.com>
Date: Thu, 19 Dec 2002 14:46:33 -0500

>Pierangelo.
>

>I suggest you enable the paged result stuff (I think it's enabled
>by default in current HEAD, the appropriate macro is in include/ldap.h)
>
>This stuff creates a sort of chicken-and-egg problem with your stuff,
>because the paging must stay in the backend to be able to resume from
>the point where the last page stopped; however, if you dup an entry
>after page-counting, you break the page counting.  I know it's shooting
>in one's foot to use the two controls simultaneously; we might well
>come out with refusing to accept them in the same request, but
>I'd like you to consider the problem.  After all paging is standard
>track, while dupent is still draft ...

I've updated the patch to refuse the request if both paged-results and
dupent controls are set. The main reason behind this move is that the
current draft ID for the dupent control does not specify how this control
should work with any other controls. More specifically, the impact that
Pierangelo stated above. The updated file is located at
ftp.openldap.org/incoming/dupent_patch.1219.tar

Followup 4

Date: Mon, 30 Dec 2002 12:34:25 -0800
To: jenarusa@us.ibm.com
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: Duplicate Entry Control Patch (ITS#2113)
Cc: openldap-its@OpenLDAP.org

Your latest tarball appears to missing at least one file
as the following routines are missing:
  create_dupent_response, process_dupent_ctrl

Kurt

At 11:47 AM 12/19/2002, jenarusa@us.ibm.com wrote:





>>Pierangelo.
>>
>
>>I suggest you enable the paged result stuff (I think it's enabled
>>by default in current HEAD, the appropriate macro is in include/ldap.h)
>>
>>This stuff creates a sort of chicken-and-egg problem with your stuff,
>>because the paging must stay in the backend to be able to resume from
>>the point where the last page stopped; however, if you dup an entry
>>after page-counting, you break the page counting.  I know it's shooting
>>in one's foot to use the two controls simultaneously; we might well
>>come out with refusing to accept them in the same request, but
>>I'd like you to consider the problem.  After all paging is standard
>>track, while dupent is still draft ...
>
>I've updated the patch to refuse the request if both paged-results and
>dupent controls are set. The main reason behind this move is that the
>current draft ID for the dupent control does not specify how this control
>should work with any other controls. More specifically, the impact that
>Pierangelo stated above. The updated file is located at
>ftp.openldap.org/incoming/dupent_patch.1219.tar