Full_Name: Version: OS: URL: Submission from: (NULL) (213.240.182.62) See motivation and disclosure considerations in list archive: https://www.openldap.org/lists/openldap-devel/201711/msg00003.html Patch will follow.
Rationale: This patch is meant to enhance user experience in case a client software is used to maintain data directly via LDAP. This is a real-world issue. Find the patch against master here: https://www.stroeder.com/temp/0001-ITS-8866-slapo-unique-to-return-filter-used-in-diagn.patch Also cleanly applies to RE24 and therefore could be easily added to upcoming release 2.4.47. ;-)
On 06/20/2018 01:26 PM, michael@stroeder.com wrote: > Find the patch against master here: > https://www.stroeder.com/temp/0001-ITS-8866-slapo-unique-to-return-filter-used-in-diagn.patch Ouch! This was not yet complete. I'll come up with a new revision soon. Ciao, Michael.
On 06/20/2018 01:41 PM, Michael Ströder wrote: > Ouch! This was not yet complete. I'll come up with a new revision soon. Please review this patch: https://www.stroeder.com/temp/0001-ITS-8866-slapo-unique-to-return-filter-used-in-diagn.patch Disclaimer: I'm not a C programmer. Thanks for your patience. Ciao, Michael.
On 06/20/2018 01:25 PM, Michael Ströder wrote: > This patch is meant to enhance user experience in case a client software > is used to maintain data directly via LDAP. This is a real-world issue. > > Find the patch against master here: > https://www.stroeder.com/temp/0001-ITS-8866-slapo-unique-to-return-filter-used-in-diagn.patch > > Also cleanly applies to RE24 and therefore > could be easily added to upcoming release 2.4.47. ;-) Any chance to see this in 2.4.47? It simply works and the patch was also reviewed by another C programmer. Ciao, Michael.
see also ITS#7738
Can someone correct the subject line of the ticket? Should of course mention slapo-unique instead of slapo-constraint.
changed state Open to Test moved from Incoming to Software Enhancements
applied to master
changed notes
--On Monday, July 30, 2018 6:58 PM +0000 michael@stroeder.com wrote: > Can someone correct the subject line of the ticket? > > Should of course mention slapo-unique instead of slapo-constraint. This patch has been applied to OpenLDAP HEAD with a correction to the memory allocation functions. I'll discuss with Howard about whether or not to add it to 2.4.47. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
On 10/26/18 4:01 AM, Quanah Gibson-Mount wrote: > --On Monday, July 30, 2018 6:58 PM +0000 michael@stroeder.com wrote: > >> Can someone correct the subject line of the ticket? >> >> Should of course mention slapo-unique instead of slapo-constraint. > > This patch has been applied to OpenLDAP HEAD with a correction to the > memory allocation functions. I'll discuss with Howard about whether or > not to add it to 2.4.47. With your memory allocation correction, op->o_tmpalloc() and op->o_tmpfree(), this does not work as expected with 2.4.x. It does *not* return the filter used for uniqueness check. (I did not test master yet.) Example for expected diagnostic message (with my original patch applied to 2.4.46): non-unique attributes found with (|(gidNumber=30041)) Result with patch backported from git master using op->o_tmpalloc() and op->o_tmpfree(): non-unique attributes found with non-unique attribute ^^^^^^^^^^^^^^^^^^^^ Seems to repeat parts of the buffer? In my original patch the use of ch_malloc() and ch_free() was simply copied from other overlay code. There are many occurences of ch_malloc() and ch_free() throughout the whole code. Does op->o_tmpalloc() and op->o_tmpfree() work correctly in RE24 branch? Ciao, Michael.
On Fri, Oct 26, 2018 at 08:12:13AM +0000, michael@stroeder.com wrote: > On 10/26/18 4:01 AM, Quanah Gibson-Mount wrote: >> This patch has been applied to OpenLDAP HEAD with a correction to the >> memory allocation functions. I'll discuss with Howard about whether or >> not to add it to 2.4.47. > > With your memory allocation correction, op->o_tmpalloc() and > op->o_tmpfree(), this does not work as expected with 2.4.x. It does > *not* return the filter used for uniqueness check. > (I did not test master yet.) > > [...] > Result with patch backported from git master using op->o_tmpalloc() and > op->o_tmpfree(): > > non-unique attributes found with non-unique attribute > ^^^^^^^^^^^^^^^^^^^^ > Seems to repeat parts of the buffer? > > In my original patch the use of ch_malloc() and ch_free() was simply > copied from other overlay code. There are many occurences of ch_malloc() > and ch_free() throughout the whole code. Yes, but `key` had already been freed a few lines earlier and using o_tmpalloc reliably exposes the issue where ch_malloc just masks it. This is now fixed in master. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
On 10/26/18 4:21 PM, Ondřej Kuzník wrote: > Yes, but `key` had already been freed a few lines earlier and using > o_tmpalloc reliably exposes the issue where ch_malloc just masks it. Ouch! > This is now fixed in master. Thanks. Everything now works like a charm also with RE24. Ciao, Michael.
*** Issue 7738 has been marked as a duplicate of this issue. ***