- openldap-bugs - openldap.org

[Bug 6567] Delete and remove everything related to ldap_gssapi_bind_s
by openldap-its＠openldap.org 09 Apr '20

09 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=6567 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |IN_PROGRESS Assignee|bugs(a)openldap.org |quanah(a)openldap.org --- Comment #13 from Quanah Gibson-Mount <quanah(a)openldap.org> --- https://git.openldap.org/openldap/openldap/-/merge_requests/28 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 6937] Remove --enable-proctitle and strdup(optarg)
by openldap-its＠openldap.org 09 Apr '20

09 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=6937 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |IN_PROGRESS Ever confirmed|0 |1 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 6937] Remove --enable-proctitle and strdup(optarg)
by openldap-its＠openldap.org 09 Apr '20

09 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=6937 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs(a)openldap.org |quanah(a)openldap.org --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- https://git.openldap.org/openldap/openldap/-/merge_requests/27 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 7335] Create process for updating man pages to handle both cn=config and slapd.conf configurations
by openldap-its＠openldap.org 09 Apr '20

09 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=7335 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Error in slapo-refint man |Create process for updating |page |man pages to handle both | |cn=config and slapd.conf | |configurations -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 8581] slapd-meta backend SSL negotiation timeout
by openldap-its＠openldap.org 09 Apr '20

09 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=8581 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |OL_2_5_REQ Summary|slapd-meta backend SSL |slapd-meta backend SSL |negociation timeout |negotiation timeout -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 8861] slapd-(async)meta(5) tls option missing ldaps
by openldap-its＠openldap.org 09 Apr '20

09 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=8861 --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- (In reply to Howard Chu from comment #3) > Sounds more like the back-ldap manpage is wrong. The use of "ldaps" is > implicit in the URI, so there's no point in supporting it here and it should > be an error to allow it here. In particular it makes no sense to allow it > here if it differs from the URI. Ok, although that doesn't entirely answer the rest of my question (i.e., about tls_reqcert etc missing from back-meta). Ironically I would note you're literally the person who added the "ldaps" option to back-ldap. a6a8fb514b (Howard Chu 2007-01-08 23:36:24 +0000 511) { BER_BVC( "ldaps" ), LDAP_BACK_F_TLS_LDAPS }, -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 8861] slapd-(async)meta(5) tls option missing ldaps
by openldap-its＠openldap.org 09 Apr '20

09 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=8861 --- Comment #3 from Howard Chu <hyc(a)openldap.org> --- (In reply to Quanah Gibson-Mount from comment #0) > Full_Name: Quanah Gibson-Mount > Version: HEAD > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.148.239) > > > The slapd-asyncmeta(5) and slapd-meta(5) man pages are missing the fact that > they support the "ldaps" option to the "tls" keyword. This section should be > updated along the lines of back-ldap which also has this option as a keyword. Sounds more like the back-ldap manpage is wrong. The use of "ldaps" is implicit in the URI, so there's no point in supporting it here and it should be an error to allow it here. In particular it makes no sense to allow it here if it differs from the URI. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 8861] slapd-(async)meta(5) tls option missing ldaps
by openldap-its＠openldap.org 09 Apr '20

09 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=8861 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 CC| |nivanova(a)symas.com Status|UNCONFIRMED |CONFIRMED --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Hi Nadya, In looking over the back-meta man page and code and comparing it to what's in back-ldap, I think the man page for back-meta needs significant updating for the TLS option. Can you confirm the following? In back-ldap, we have: tls {none|[try-]start|[try-]propagate|ldaps} [starttls=no] [tls_cert=<file>] [tls_key=<file>] [tls_cacert=<file>] [tls_cacertdir=<path>] [tls_reqcert=never|allow|try|demand] [tls_cipher_suite=<ciphers>] [tls_crlcheck=none|peer|all] Specify TLS settings for regular connections. The first parameter only applies to ldap:// connections and so at the moment, none and ldaps are equivalent. With propagate, the proxy issues StartTLS operation only if the original connection has a TLS layer set up. The try- prefix instructs the proxy to continue operations if the StartTLS operation failed; its use is not recommended. The TLS settings default to the same as the main slapd TLS settings, except for tls_reqcert which defaults to "demand" and starttls which is overshadowed by the first keyword and thus ignored. I believe all of the above options also apply to back-meta. Are the caveats about tls_reqcert the same? For back-meta, all we have currently is: tls {[try-]start|[try-]propagate} execute the StartTLS extended operation when the connection is initialized; only works if the URI directive protocol scheme is not ldaps://. propagate issues the StartTLS operation only if the original connection did. The try- prefix instructs the proxy to continue operations if the StartTLS operation failed; its use is highly deprecated. If set before any target specification, it affects all targets, unless overridden by any per-target directive. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 8861] slapd-(async)meta(5) tls option missing ldaps
by openldap-its＠openldap.org 09 Apr '20

09 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=8861 --- Comment #1 from Quanah Gibson-Mount <quanah(a)openldap.org> --- "none" is also missing -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 9156] latest ppolicy draft support
by openldap-its＠openldap.org 09 Apr '20

09 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=9156 --- Comment #9 from David Coutadeur <david.coutadeur(a)gmail.com> --- Hello, Thanks Ondřej for your answer to my test results. Here are some updates! > - pwdLastSuccess, pwdMaxIdle: KO: the user is able to authenticate after the > pwdMaxIdle delay. Also, the pwdLastSuccess is never written (see > https://tools.ietf.org/html/draft-behera-ldap-password-policy-10#section-5.…). > For information, I have enabled lastbind. The slapo-ppolicy man page does not > mention pwdLastSuccess by the way. I finally succeeded in making it work. Thanks for pointing test022-ppolicy, it was helpfull. The problem was that I was using old lastbind overlay, which in some way was in conflict with current lastbind. If I understand correctly, the current lastbind is now completely included into OpenLDAP 2.5? It is very important to me, because as a maintainer of OpenLDAP-LTB, we would have to warn people that the configuration parameters have changed (overlay lastbind -> lastbind on) and that the overlay won't be provided any more. > - pwdStartTime, pwdEndTime: OK, but there is no special ppolicy code returned, > and if I read correctly the draft > (https://tools.ietf.org/html/draft-behera-ldap-password-policy-10#section-7.1), > an "accountLocked" extended error code should be triggered. I was simply missing the ppolicy_use_lockout parameter. One remark though: the reason of locking is not very explicit. I understand that many companies/organizations will consider it is a good thing to hide this information for security reasons. For the others, maybe could we have some sort of level? Configuration example: lockout_message_description [none|minimal|verbose] In the specification the extended error code could simply stay as it is: "(1)Account locked", but we could add a more precise description in case the verbose mode is enabled: "(1)Account locked (account unused for a too long time)" Regards, David -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 8893] New LDAP option to support binding to specific IPv4/IPv6 address at client side
by openldap-its＠openldap.org 08 Apr '20

08 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=8893 Ryan Tandy <ryan(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |DUPLICATE --- Comment #7 from Ryan Tandy <ryan(a)openldap.org> --- *** This bug has been marked as a duplicate of bug 8847 *** -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 8847] New LDAP URL syntax to support binding to specific IP address at client side
by openldap-its＠openldap.org 08 Apr '20

08 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=8847 Ryan Tandy <ryan(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sudhir.singam(a)gmail.com --- Comment #30 from Ryan Tandy <ryan(a)openldap.org> --- *** Bug 8893 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 9098] assert fails in meta_back_search in some cases after reconnect
by openldap-its＠openldap.org 08 Apr '20

08 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=9098 --- Comment #11 from maxime.besson(a)worteks.com <maxime.besson(a)worteks.com> --- My original report mentions it: candidates[ i ].sr_msgid is -1 (META_MSGID_IGNORE) -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 9098] assert fails in meta_back_search in some cases after reconnect
by openldap-its＠openldap.org 08 Apr '20

08 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=9098 --- Comment #10 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Ok, it is halting on this check: assert( candidates[ i ].sr_msgid >= 0 || candidates[ i ].sr_msgid == META_MSGID_CONNECTING ); So what we need is in thread 1, frame 2, to know what the value of candidates[i].sr_msgid is. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 9098] assert fails in meta_back_search in some cases after reconnect
by openldap-its＠openldap.org 08 Apr '20

08 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=9098 --- Comment #9 from maxime.besson(a)worteks.com <maxime.besson(a)worteks.com> --- Created attachment 705 --> https://bugs.openldap.org/attachment.cgi?id=705&action=edit A more complete backtrace Sorry about that, hopefully this one is more useable -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 9098] assert fails in meta_back_search in some cases after reconnect
by openldap-its＠openldap.org 08 Apr '20

08 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=9098 --- Comment #8 from Quanah Gibson-Mount <quanah(a)openldap.org> --- (In reply to maxime.besson(a)worteks.com from comment #7) > Created attachment 704 [details] > assert backtrace > > A little bird told be this report was missing a backtrace. What we need is a full backtrace. ;) thr apply all bt full -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 9098] assert fails in meta_back_search in some cases after reconnect
by openldap-its＠openldap.org 08 Apr '20

08 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=9098 --- Comment #7 from maxime.besson(a)worteks.com <maxime.besson(a)worteks.com> --- Created attachment 704 --> https://bugs.openldap.org/attachment.cgi?id=704&action=edit assert backtrace A little bird told be this report was missing a backtrace. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 8296] slapd suddenly crash when using syncprov
by openldap-its＠openldap.org 08 Apr '20

08 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=8296 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|FEEDBACK |SUSPENDED Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 8296] slapd suddenly crash when using syncprov
by openldap-its＠openldap.org 07 Apr '20

07 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=8296 --- Comment #11 from maurizio.lattuada(a)gmail.com <maurizio.lattuada(a)gmail.com> --- Hi Quanah, unfortunately I'm not working on that project anymore (not for that company too), so I had not anymore the chance to figure it out. Sorry for that. Cheers, Maurizio Il giorno dom 22 mar 2020 alle ore 01:53 <openldap-its(a)openldap.org> ha scritto: > https://bugs.openldap.org/show_bug.cgi?id=8296 > > Quanah Gibson-Mount <quanah(a)openldap.org> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > Status|UNCONFIRMED |RESOLVED > Resolution|--- |FEEDBACK > > --- Comment #10 from Quanah Gibson-Mount <quanah(a)openldap.org> --- > Hi Maurizio, > > Do you still hit this issue with the current release? I apologize for the > delay in response. Numerous fixes and changes have been made to syncprov > since > this was filed. > > Regards, > Quanah > > -- > You are receiving this mail because: > You reported the bug. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 9179] back-ldap SASL proxy authorization
by openldap-its＠openldap.org 07 Apr '20

07 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=9179 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9205 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 9121] dynlist enhancements
by openldap-its＠openldap.org 07 Apr '20

07 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=9121 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|CONFIRMED |RESOLVED -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 9121] dynlist enhancements
by openldap-its＠openldap.org 07 Apr '20

07 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=9121 --- Comment #4 from Howard Chu <hyc(a)openldap.org> --- (In reply to Quanah Gibson-Mount from comment #3) > Current code periodically triggers a SEGV in test044: fixed in 5bfd8d88887eff4581463cb20f9262bf51686908 > > (gdb) cont > Continuing. > [New Thread 0x7fd9d2ce2700 (LWP 18294)] > [New Thread 0x7fd9d24e1700 (LWP 18295)] > > Thread 3 "lt-slapd" received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7fd9d2ce2700 (LWP 18294)] > 0x00007fd9d42a697c in comp_candidates (op=0x7fd9c4002900, > rtxn=0x7fd9c410ad10, mra=0x7fd9c4005430, f=0x1c, ids=0x7fd9d0c5f018, > tmp=0x7fd9d095f018, stack=0x7fd9d0d5f018) > at filterindex.c:464 > 464 filterindex.c: No such file or directory. > > > #0 0x00007fd9d42a697c in comp_candidates (op=0x7fd9c4002900, > rtxn=0x7fd9c410ad10, mra=0x7fd9c4005430, f=0x1c, ids=0x7fd9d0c5f018, > tmp=0x7fd9d095f018, stack=0x7fd9d0d5f018) > at filterindex.c:464 > rc = 1409434333 > #1 0x00007fd9d42a6bb2 in ext_candidates (op=0x7fd9c4002900, > rtxn=0x7fd9c410ad10, mra=0x7fd9c4005430, ids=0x7fd9d0c5f018, > tmp=0x7fd9d095f018, stack=0x7fd9d0d5f018) > at filterindex.c:507 > No locals. > #2 0x00007fd9d42a5c0f in mdb_filter_candidates (op=0x7fd9c4002900, > rtxn=0x7fd9c410ad10, f=0x7fd9c4005410, ids=0x7fd9d0c5f018, > tmp=0x7fd9d095f018, stack=0x7fd9d0d5f018) > at filterindex.c:206 > rc = 0 > aa = 0x7fd9c40016c0 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 9121] dynlist enhancements
by openldap-its＠openldap.org 07 Apr '20

07 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=9121 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|TEST |--- Status|RESOLVED |CONFIRMED --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Current code periodically triggers a SEGV in test044: (gdb) cont Continuing. [New Thread 0x7fd9d2ce2700 (LWP 18294)] [New Thread 0x7fd9d24e1700 (LWP 18295)] Thread 3 "lt-slapd" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fd9d2ce2700 (LWP 18294)] 0x00007fd9d42a697c in comp_candidates (op=0x7fd9c4002900, rtxn=0x7fd9c410ad10, mra=0x7fd9c4005430, f=0x1c, ids=0x7fd9d0c5f018, tmp=0x7fd9d095f018, stack=0x7fd9d0d5f018) at filterindex.c:464 464 filterindex.c: No such file or directory. #0 0x00007fd9d42a697c in comp_candidates (op=0x7fd9c4002900, rtxn=0x7fd9c410ad10, mra=0x7fd9c4005430, f=0x1c, ids=0x7fd9d0c5f018, tmp=0x7fd9d095f018, stack=0x7fd9d0d5f018) at filterindex.c:464 rc = 1409434333 #1 0x00007fd9d42a6bb2 in ext_candidates (op=0x7fd9c4002900, rtxn=0x7fd9c410ad10, mra=0x7fd9c4005430, ids=0x7fd9d0c5f018, tmp=0x7fd9d095f018, stack=0x7fd9d0d5f018) at filterindex.c:507 No locals. #2 0x00007fd9d42a5c0f in mdb_filter_candidates (op=0x7fd9c4002900, rtxn=0x7fd9c410ad10, f=0x7fd9c4005410, ids=0x7fd9d0c5f018, tmp=0x7fd9d095f018, stack=0x7fd9d0d5f018) at filterindex.c:206 rc = 0 aa = 0x7fd9c40016c0 #3 0x00007fd9d42a6ee5 in list_candidates (op=0x7fd9c4002900, rtxn=0x7fd9c410ad10, flist=0x7fd9c4005410, ftype=160, ids=0x7fd9d0b5f018, tmp=0x7fd9d095f018, save=0x7fd9d0c5f018) at filterindex.c:582 rc = 0 f = 0x7fd9c4005410 #4 0x00007fd9d42a5ae1 in mdb_filter_candidates (op=0x7fd9c4002900, rtxn=0x7fd9c410ad10, f=0x7fd9c4003b40, ids=0x7fd9d0b5f018, tmp=0x7fd9d095f018, stack=0x7fd9d0c5f018) at filterindex.c:195 rc = 0 aa = 0x7fd9d2cd0190 #5 0x00007fd9d42a6ee5 in list_candidates (op=0x7fd9c4002900, rtxn=0x7fd9c410ad10, flist=0x7fd9c4003b40, ftype=160, ids=0x7fd9d0a5f018, tmp=0x7fd9d095f018, save=0x7fd9d0b5f018) at filterindex.c:582 rc = 0 f = 0x7fd9c4003b40 #6 0x00007fd9d42a5ae1 in mdb_filter_candidates (op=0x7fd9c4002900, rtxn=0x7fd9c410ad10, f=0x7fd9c4003b20, ids=0x7fd9d0a5f018, tmp=0x7fd9d095f018, stack=0x7fd9d0b5f018) at filterindex.c:195 rc = 0 aa = 0x0 #7 0x00007fd9d42a6ee5 in list_candidates (op=0x7fd9c4002900, rtxn=0x7fd9c410ad10, flist=0x7fd9d2cd0390, ftype=161, ids=0x7fd9d07df018, tmp=0x7fd9d095f018, save=0x7fd9d0a5f018) at filterindex.c:582 rc = 0 f = 0x7fd9c4003b20 #8 0x00007fd9d42a5b7c in mdb_filter_candidates (op=0x7fd9c4002900, rtxn=0x7fd9c410ad10, f=0x7fd9d2cd03b0, ids=0x7fd9d07df018, tmp=0x7fd9d095f018, stack=0x7fd9d0a5f018) at filterindex.c:201 rc = 0 aa = 0x0 #9 0x00007fd9d42a10e7 in search_candidates (op=0x7fd9c4002900, rs=0x7fd9d2ce1a70, e=0x7fd9c4005578, isc=0x7fd9d2cd0670, mci=0x7fd9c4001530, ids=0x7fd9d07df018, stack=0x7fd9d095f018) at search.c:1411 mdb = 0x7fd9d418c010 rc = 0 depth = 4 f = 0x7fd9d2cd03b0 rf = {f_choice = 163, f_un = {f_un_result = -758316016, f_un_desc = 0x7fd9d2cd0410, f_un_ava = 0x7fd9d2cd0410, f_un_ssa = 0x7fd9d2cd0410, f_un_mra = 0x7fd9d2cd0410, f_un_complex = 0x7fd9d2cd0410}, f_next = 0x7fd9c4003b20} xf = {f_choice = 161, f_un = {f_un_result = -758316144, f_un_desc = 0x7fd9d2cd0390, f_un_ava = 0x7fd9d2cd0390, f_un_ssa = 0x7fd9d2cd0390, f_un_mra = 0x7fd9d2cd0390, f_un_complex = 0x7fd9d2cd0390}, f_next = 0x0} nf = {f_choice = 140573521282144, f_un = {f_un_result = -758315808, f_un_desc = 0x7fd9d2cd04e0, f_un_ava = 0x7fd9d2cd04e0, f_un_ssa = 0x7fd9d2cd04e0, f_un_mra = 0x7fd9d2cd04e0, f_un_complex = 0x7fd9d2cd04e0}, f_next = 0x0} sf = {f_choice = 8, f_un = {f_un_result = -735244463, f_un_desc = 0x7fd9d42d0f51, f_un_ava = 0x7fd9d42d0f51, f_un_ssa = 0x7fd9d42d0f51, f_un_mra = 0x7fd9d42d0f51, f_un_complex = 0x7fd9d42d0f51}, f_next = 0x7fd9c4005578} aa_ref = {aa_desc = 0x55ebd3472230, aa_value = {bv_len = 8, bv_val = 0x7fd9d42d0f51 "referral"}, aa_cf = 0x0} aa_subentry = {aa_desc = 0x0, aa_value = {bv_len = 0, bv_val = 0x0}, aa_cf = 0x0} #10 0x00007fd9d429e856 in mdb_search (op=0x7fd9c4002900, rs=0x7fd9d2ce1a70) at search.c:677 mdb = 0x7fd9d418c010 id = 18446744073709551615 cursor = 2 nsubs = 13 ncand = 1 cscope = 94471351201400 lastid = 18446744073709551615 candidates = 0x7fd9d07df018 iscopes = 0x7fd9d08df018 c0 = 0x7fd9d07df018 scopes = 0x7fd9d19e0010 stack = 0x7fd9d095f018 e = 0x0 base = 0x7fd9c4005578 matched = 0x0 attrs = 0x7fd9c4003a38 mask = 4159 stoptime = 1586274302 manageDSAit = 0 tentries = 0 isc = <error reading variable isc (value of type `IdScopes' requires 65592 bytes, which is more than max-value-size)> mci = 0x7fd9c4001530 mcd = 0x7fd9c4000d20 wwctx = {txn = 0x7fd9c410ad10, mcd = 0x0, key = 140573521282720, data = {mv_size = 140573544266088, mv_data = 0x8d2cd06f0}, flag = 0, nentries = 1} cb = {sc_next = 0x0, sc_response = 0x0, sc_cleanup = 0x0, sc_private = 0x0, sc_writewait = 0x0} opinfo = {moi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x7fd9d418c010}, moi_txn = 0x7fd9c410ad10, moi_ref = 1, moi_flag = 1 '\001'} moi = 0x7fd9d2cd05c0 ltid = 0x7fd9c410ad10 #11 0x000055ebd3064d9c in overlay_op_walk (op=0x7fd9c4002900, rs=0x7fd9d2ce1a70, which=op_search, oi=0x55ebd34b9f50, on=0x0) at backover.c:706 bi = 0x7fd9d42da1a0 <bi> rc = 32768 #12 0x000055ebd3065055 in over_op_func (op=0x7fd9c4002900, rs=0x7fd9d2ce1a70, which=op_search) at backover.c:766 oi = 0x55ebd34b9f50 on = 0x55ebd34f9b00 be = 0x55ebd34f76f0 db = {bd_info = 0x7fd9d42da1a0 <bi>, bd_self = 0x55ebd34f76f0, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\001", '\000' <repeats 16 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x55ebd34f98b0, be_nsuffix = 0x55ebd34f98e0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 28, bv_val = 0x55ebd34f9980 "cn=Manager,dc=example,dc=com"}, be_rootndn = {bv_len = 28, bv_val = 0x55ebd34f99d0 "cn=manager,dc=example,dc=com"}, be_rootpw = {bv_len = 6, bv_val = 0x55ebd34f9810 "secret"}, be_max_deref_depth = 15, be_def_limit = { lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x7fd9c810d2f0, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x55ebd35ae4e0, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x7fd9d42d9e20 <mdbocs+64>, be_private = 0x7fd9d418c010, be_next = {stqe_next = 0x0}} sc = 0x55ebd34f9b00 cb = 0x7fd9c4003a90 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #13 0x000055ebd30651cd in over_op_search (op=0x7fd9c4002900, rs=0x7fd9d2ce1a70) at backover.c:796 No locals. #14 0x000055ebd2fc6aaa in fe_op_search (op=0x7fd9c4002900, rs=0x7fd9d2ce1a70) at search.c:406 bd = 0x55ebd30fc680 <slap_frontendDB> #15 0x000055ebd2fc6294 in do_search (op=0x7fd9c4002900, rs=0x7fd9d2ce1a70) at search.c:247 base = {bv_len = 27, bv_val = 0x7fd9c428fe98 "ou=People,dc=example,dc=com"} siz = 1 off = 0 i = 1 #16 0x000055ebd2fc280f in connection_operation (ctx=0x7fd9d2ce1bd0, arg_v=0x7fd9c4002900) at connection.c:1174 rc = 80 cancel = 32729 op = 0x7fd9c4002900 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = { r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = { r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 99 opidx = SLAP_OP_SEARCH conn = 0x7fd9d40e8ed0 memctx = 0x7fd9c4002e70 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #17 0x000055ebd2fc2f2f in connection_read_thread (ctx=0x7fd9d2ce1bd0, argv=0xc) at connection.c:1325 rc = 0 cri = {op = 0x7fd9c4002900, func = 0x0, arg = 0x0, ctx = 0x7fd9d2ce1bd0, nullop = 0} s = 12 #18 0x00007fd9d4d1d3ea in ldap_int_thread_pool_wrapper (xpool=0x55ebd34a1040) at tpool.c:1048 pq = 0x55ebd34a1040 pool = 0x55ebd34a0f30 task = 0x7fd9cc000b20 work_list = 0x55ebd34a10b0 ctx = {ltu_pq = 0x55ebd34a1040, ltu_id = 140573521356544, ltu_key = {{ltk_key = 0x55ebd2fc1f1f <conn_counter_init>, ltk_data = 0x7fd9c4002d60, ltk_free = 0x55ebd2fc1d34 <conn_counter_destroy>}, {ltk_key = 0x55ebd303f0f0 <slap_sl_mem_init>, ltk_data = 0x7fd9c4002e70, ltk_free = 0x55ebd303ef07 <slap_sl_mem_destroy>}, {ltk_key = 0x55ebd2fde919 <slap_op_free>, ltk_data = 0x0, ltk_free = 0x55ebd2fde86a <slap_op_q_destroy>}, { ltk_key = 0x55ebd35ae500, ltk_data = 0x7fd9c410ad10, ltk_free = 0x7fd9d42ae3e9 <mdb_reader_free>}, {ltk_key = 0x7fd9d42a0ad8 <search_stack>, ltk_data = 0x7fd9d07df010, ltk_free = 0x7fd9d42a0ab4 <search_stack_free>}, {ltk_key = 0x7fd9d429d288 <scope_chunk_get>, ltk_data = 0x7fd9d04de010, ltk_free = 0x7fd9d429d23f <scope_chunk_free>}, {ltk_key = 0x0, ltk_data = 0x7fd9c8000cd0, ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 25 times>}} kctx = 0x0 i = 32 keyslot = 831 hash = 391062335 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #19 0x00007fd9d497efa3 in start_thread (arg=<optimized out>) at pthread_create.c:486 ret = <optimized out> pd = <optimized out> now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140573521356544, 516393886524641449, 140573529738174, 140573529738175, 140573521356544, 0, -533328986613477207, -533341552069701463}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> #20 0x00007fd9d444b4cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 No locals. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 8245] slapo-unique constraints bypassed by manageDsaIt, change to relax?
by openldap-its＠openldap.org 07 Apr '20

07 Apr '20

1 0

[Bug 8245] slapo-unique constraints bypassed by manageDsaIt, change to relax?
by openldap-its＠openldap.org 07 Apr '20

07 Apr '20

https://bugs.openldap.org/show_bug.cgi?id=8245 --- Comment #14 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • 6d6a3300 by Ondřej Kuzník at 2020-04-06T20:44:09+00:00 ITS#8245 Use Relax control to avoid uniqueness checks Still needs to retrieve the entry for ACL resolution until we can restrict controls with ACLs -- You are receiving this mail because: You are on the CC list for the bug.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs