openldap-bugs January 2021

openldap-bugs@openldap.org

1 participants
300 discussions

[Issue 9337] New: Slapd crash with lastbind overlay
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=9337 Issue ID: 9337 Summary: Slapd crash with lastbind overlay Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: frederic.poisson(a)admin.gmessaging.net Target Milestone: --- Hello, I have an issue with a 2.4.50 OpenLDAP instance configured with replication (1 master and 1 replica), and when i activate the lastbind overlay. The replica server crash like this : slapd[8433]: segfault at 1d0 ip 000000000049f70b sp 00007f189f7fd1a0 error 4 in slapd[400000+1d8000] The database is this one with overlay loaded : dn: cn=module{0},cn=config olcModuleLoad: {0}sssvlv.la olcModuleLoad: {1}ppolicy.la olcModuleLoad: {2}syncprov.la olcModuleLoad: {3}lastbind.la olcModuleLoad: {4}pw-sha2.la dn: olcDatabase={3}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcUpdateRef: ldap://master.server:389/ If i add this configuration it crash : dn: olcOverlay={2}lastbind objectClass: olcOverlayConfig objectClass: olcLastBindConfig olcOverlay: {2}lastbind olcLastBindPrecision: 60 olcLastBindForwardUpdates: TRUE Does the release 2.5.51 or 2.5.52 could solve this issue ? Regards, -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 9445] New: ITS#9339/1748ec59a crashes slapd on ip connect in tcpwrappers
by openldap-its＠openldap.org 01 Apr '21

01 Apr '21

https://bugs.openldap.org/show_bug.cgi?id=9445 Issue ID: 9445 Summary: ITS#9339/1748ec59a crashes slapd on ip connect in tcpwrappers Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: grapvar(a)gmail.com Target Milestone: --- When openldap is configured with tcpwrappers, servers/slapd/daemon.c`slap_listener() calls: > hosts_ctl("slapd", dnsname != NULL ? dnsname : SLAP_STRING_UNKNOWN, > peeraddr, ... where `peeraddr' must be client ip addr or literal "unknown" string. Commit [2020-09-06 1748ec59a ITS#9339 Add syncrepl status to cn=monitor] is made so that `peeraddr' contains fixed NULL value. This causes immediate crash of slapd inside tcpwrappers library when client connects using ip protocol at least on Solaris x86-64. I did not verify this on linux, but even if slapd doesn't crash on linux, then tcpwrappers do not work as expected anyway. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9446] New: back_passwd: invalid parsing of gecos field
by openldap-its＠openldap.org 31 Mar '21

31 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=9446 Issue ID: 9446 Summary: back_passwd: invalid parsing of gecos field Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: grapvar(a)gmail.com Target Milestone: --- Created attachment 788 --> https://bugs.openldap.org/attachment.cgi?id=788&action=edit fix Parsing gecos(comment) field of /etc/passwd in servers/slapd/back-passwd/search.c`pw2entry() has issues. I expands '&': 1) anywhere in in gecos, but the expansion must be limited by user's full name. 2) only 1st '&', but all `&'s in full name must be expanded (nice explanation: https://unix.stackexchange.com/questions/535189/ampersand-in-the-passwd-gec…) fix attached. It expands each `&', left to right, until expanded user's full name fits into internal { char buf[1024]; } -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 9382] New: client tools ldapvc.c tracks criticality but doesn't use it
by openldap-its＠openldap.org 31 Mar '21

31 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=9382 Issue ID: 9382 Summary: client tools ldapvc.c tracks criticality but doesn't use it Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- In clients/toolsldapv.c, we have: switch ( i ) { char *control, *cvalue; int crit; ... case 'E': /* vc extension */ crit = 0; if( optarg[0] == '!' ) { crit = 1; and then we never use "crit" again. It would appear the intention was to determine whether or not this control is marked critical and then do something based on that, but there is in fact nothing ever done. This leads to a warning that crit is set but unused. If the criticality of the control doesn't matter, than this variable should be eliminated. If it does matter, then the missing code needs to be added. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9288] New: slapd service stops suddenly but generates crash file
by openldap-its＠openldap.org 31 Mar '21

31 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=9288 Issue ID: 9288 Summary: slapd service stops suddenly but generates crash file Product: OpenLDAP Version: 2.4.49 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: tekkitan(a)gmail.com Target Milestone: --- System: t3.small AWS instance 2VCPU 2GB RAM OS: Ubuntu 20.04 (was happening on 16.04 as well) Package Version: 2.4.49+dfsg-2ubuntu1.2 We've been having this weird problem with slapd between Ubuntu 16.04 and Ubuntu 20.04 where slapd will suddenly stop according to syslog but will also generate a crash file within apport. We thought it was due to some weird stuff we were doing in the 16.04 version (2.4.42+dfsg-2ubuntu3.8), but we deployed a new LDAP proxy in 20.04 (2.4.49+dfsg-2ubuntu1.2) which appears to have the same issue so I am reporting it and hoping for guidance as we use this proxy for our corporate VPN. Below is the backtrace which was the same from both proxy systems, but this one is from the 20.04 version as that is our current system in use: root@useldap02:~/_usr_sbin_slapd.0.crash# apport-retrace --stdout /var/crash/_usr_sbin_slapd.0.crash --- stack trace --- #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 set = {__val = {0, 140488162916432, 140488307736576, 140487911640016, 140487911640117, 140487911640016, 140487911640016, 140487911640147, 140487911640316, 140487911640016, 140487911640316, 0, 0, 0, 0, 0}} pid = <optimized out> tid = <optimized out> ret = <optimized out> #1 0x00007fc5f3043859 in __GI_abort () at abort.c:79 save_stage = 1 act = {__sigaction_handler = {sa_handler = 0x2, sa_sigaction = 0x2}, sa_mask = {__val = {131, 4, 99, 0, 0, 140488164070405, 0, 21474836480, 140488121483504, 0, 140488164102160, 0, 6703301646461552640, 140488164070405, 140488165695488, 140488164087176}}, sa_flags = -235332728, sa_restorer = 0xbf} sigs = {__val = {32, 0 <repeats 15 times>}} #2 0x00007fc5f3043729 in __assert_fail_base (fmt=0x7fc5f31d9588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7fc5f1f91953 "!LDAP_BACK_CONN_TAINTED( lc )", file=0x7fc5f1f91b88 "../../../../../servers/slapd/back-ldap/bind.c", line=191, function=<optimized out>) at assert.c:92 str = 0x7fc5c410a280 "@Q\021\344\305\177" total = 4096 #3 0x00007fc5f3054f36 in __GI___assert_fail (assertion=0x7fc5f1f91953 "!LDAP_BACK_CONN_TAINTED( lc )", file=0x7fc5f1f91b88 "../../../../../servers/slapd/back-ldap/bind.c", line=191, function=0x7fc5f1f921a0 "ldap_back_conn_delete") at assert.c:101 No locals. #4 0x00007fc5f1f807c7 in ldap_back_conn_delete () from /usr/lib/ldap/back_ldap-2.4.so.2 No symbol table info available. #5 0x00007fc5f1f814a4 in ?? () from /usr/lib/ldap/back_ldap-2.4.so.2 No symbol table info available. #6 0x00007fc5f1f815ad in ldap_back_release_conn_lock () from /usr/lib/ldap/back_ldap-2.4.so.2 No symbol table info available. #7 0x00007fc5f1f833bc in ldap_back_retry () from /usr/lib/ldap/back_ldap-2.4.so.2 No symbol table info available. #8 0x00007fc5f1f7ec0b in ldap_back_search () from /usr/lib/ldap/back_ldap-2.4.so.2 No symbol table info available. #9 0x000055b87105cc88 in overlay_op_walk () No symbol table info available. #10 0x000055b87105cdb7 in ?? () No symbol table info available. #11 0x000055b870fef80d in fe_op_search () No symbol table info available. #12 0x000055b870fef034 in do_search () No symbol table info available. #13 0x000055b870fec6ed in ?? () No symbol table info available. #14 0x000055b870fed22c in ?? () No symbol table info available. #15 0x00007fc5f32e7a03 in ?? () from /lib/x86_64-linux-gnu/libldap_r-2.4.so.2 No symbol table info available. #16 0x00007fc5f3219609 in start_thread (arg=<optimized out>) at pthread_create.c:477 ret = <optimized out> pd = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140488121493248, -8220430158823943899, 140488129874654, 140488129874655, 140488129874784, 140488121490880, 8241811018110734629, 8241811687867814181}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = 0 #17 0x00007fc5f3140103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 No locals. This is usually what we see within syslog when slapd stops: Jul 11 00:49:32 useldap02 slapd[5257]: conn=1035 op=239 SRCH base="ou=people,dc=company,dc=com" scope=2 deref=0 filter="(&(|(objectClass=person)(objectClass=organizationalPerson)(objectClass=inetOrgPerson)(?objectClass=fw1Person))(uid=exampleusername))" Jul 11 00:49:32 useldap02 slapd[5257]: conn=1035 op=239 SRCH attr=cn uid sn mail proxyAddresses userPrincipalName fullName displayName description objectclass fw1hour-range-from fw1hour-range-to fw1expiration-date fw1day fw1allowed-dst fw1allowed-src fw1auth-method userAccountControl fw1userPwdPolicy mobile fw1BadPwdCount fw1lastLoginFailure fw1pwdLastMod fw1auth-server fw1auth-server fw1groupTemplate fw1sr-auth-track fw1enc-methods fw1ISAKMP-EncMethod fw1ISAKMP-AuthMethods fw1ISAKMP-HashMethods fw1ISAKMP-Transform fw1ISAKMP-DataIntegrityMethod fw1ISAKMP-SharedSecret fw1ISAKMP-DataEncMethod givenName surname Jul 11 00:49:32 useldap02 slapd[5257]: conn=1035 op=240 SRCH base="ou=groups,dc=company,dc=com" scope=2 deref=0 filter="(&(|(objectClass=person)(objectClass=organizationalPerson)(objectClass=inetOrgPerson)(?objectClass=fw1Person))(uid=exampleusername))" Jul 11 00:49:32 useldap02 slapd[5257]: conn=1035 op=240 SRCH attr=cn uid sn mail proxyAddresses userPrincipalName fullName displayName description objectclass fw1hour-range-from fw1hour-range-to fw1expiration-date fw1day fw1allowed-dst fw1allowed-src fw1auth-method userAccountControl fw1userPwdPolicy mobile fw1BadPwdCount fw1lastLoginFailure fw1pwdLastMod fw1auth-server fw1auth-server fw1groupTemplate fw1sr-auth-track fw1enc-methods fw1ISAKMP-EncMethod fw1ISAKMP-AuthMethods fw1ISAKMP-HashMethods fw1ISAKMP-Transform fw1ISAKMP-DataIntegrityMethod fw1ISAKMP-SharedSecret fw1ISAKMP-DataEncMethod givenName surname Jul 11 00:49:34 useldap02 slapd[28099]: * Stopping OpenLDAP slapd Jul 11 00:49:34 useldap02 slapd[28099]: ...done. Jul 11 00:49:34 useldap02 systemd[1]: slapd.service: Succeeded. Note that a lot of these attributes being searched for (all the fw1* attributes) do not exist within our LDAP. Not sure if that would be the cause. Thank you for any help that can be provided. -- You are receiving this mail because: You are on the CC list for the issue.

1 13

[Issue 9270] New: Admin guide: Add detailed information on indexing
by openldap-its＠openldap.org 31 Mar '21

31 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=9270 Issue ID: 9270 Summary: Admin guide: Add detailed information on indexing Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- It would be useful to outline what the different types of indexing options do, and when they are useful, in the admin guide. For example: presence indexing is only useful if looking to find entries with a given attribute, when generally < 50% of the entries in the DB have an instance of that attribute. equality indexing would not be particularly useful on an attribute that exists in most every entry, and the attribute always has the same value etc. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Bug 9260] New: slapd-ldap(5) man page missing conn-pool-max option
by openldap-its＠openldap.org 31 Mar '21

31 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=9260 Bug ID: 9260 Summary: slapd-ldap(5) man page missing conn-pool-max option Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The slapd-ldap(5) man page is missing any information on the conn-pool-max configuration option. Part of ITS#4791 -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 9241] New: olcRefintNothing refuse to accept space in the target dn
by openldap-its＠openldap.org 31 Mar '21

31 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=9241 Bug ID: 9241 Summary: olcRefintNothing refuse to accept space in the target dn Product: OpenLDAP Version: 2.4.49 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: sebastien.chaumat(a)qspin.be Target Milestone: --- When configuring refint : dn: olcOverlay={2}refint,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcRefintConfig olcOverlay: {2}refint olcRefintAttribute: seeAlso olcRefintNothing: cn=admin,dc=test is accepted but olcRefintNothing: cn=admin space,dc=test is rejected when I ldapadd the configuration with the message : ldap_add: Constraint violation (19) additional info: <olcRefintNothing> extra cruft after <string> I tried various quoting : cn="admin space",dc=test cn=admin\20space "cn=admin space" -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Issue 9421] New: SIGSEGV in the MMR synchro
by openldap-its＠openldap.org 22 Mar '21

22 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=9421 Issue ID: 9421 Summary: SIGSEGV in the MMR synchro Product: OpenLDAP Version: 2.4.56 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: benjamin.demarteau(a)liege.be Target Milestone: --- We are in the process of migrating from a single outdated node to an up to date MMR cluster. Through this process we write LSC synchronizations from the old server to the new server so we can keep the old server around. Our preliminary tests show that when LSC hammers the ldap using multiple threads while another node is included in the replication, we get segmentation faults with the following backtrace: #0 0x00007f7f578748ef in __strncasecmp_l_avx () from /lib64/libc.so.6 #1 0x000056094a7ca298 in avl_find (root=0x56094bb28820, data=data@entry=0x7f7e74000cd0, fcmp=fcmp@entry=0x56094a7166a0 <oc_index_name_cmp>) at avl.c:545 #2 0x000056094a716bde in oc_bvfind (ocname=0x7f7e74000cd0) at oc.c:186 #3 oc_bvfind (ocname=ocname@entry=0x7f7e74000cd0) at oc.c:178 #4 0x000056094a70ec5a in objectSubClassMatch (matchp=0x7f7e5fff8c8c, flags=256, syntax=<optimized out>, mr=<optimized out>, value=<optimized out>, assertedValue=0x7f7e74000cd0) at schema_prep.c:214 #5 0x000056094a6e9fb9 in ordered_value_match (match=match@entry=0x7f7e5fff8c8c, ad=0x56094bb184e0, mr=mr@entry=0x56094bb09810, flags=flags@entry=256, v1=v1@entry=0x7f7e5810f470, v2=v2@entry=0x7f7e74000cd0, text=0x7f7e5fff8c90) at value.c:693 #6 0x000056094a6ec44d in test_ava_filter (op=op@entry=0x7f7e5fff90c0, e=e@entry=0x56094bb54a88, ava=0x7f7e74000cc8, type=type@entry=163) at filterentry.c:777 #7 0x000056094a6ecfec in test_filter (op=op@entry=0x7f7e5fff90c0, e=e@entry=0x56094bb54a88, f=f@entry=0x7f7e74000d08) at filterentry.c:88 #8 0x000056094a6ecc81 in test_filter_and (flist=<optimized out>, e=0x56094bb54a88, op=0x7f7e5fff90c0) at filterentry.c:879 #9 test_filter (op=op@entry=0x7f7e5fff90c0, e=0x56094bb54a88, f=<optimized out>) at filterentry.c:118 #10 0x00007f7f5382c58f in syncprov_matchops (op=op@entry=0x7f7e5fff9c80, opc=opc@entry=0x7f7e58001808, saveit=saveit@entry=0) at syncprov.c:1393 #11 0x00007f7f5382e37f in syncprov_op_response (op=0x7f7e5fff9c80, rs=<optimized out>) at syncprov.c:2115 #12 0x000056094a6dcb98 in slap_response_play (op=op@entry=0x7f7e5fff9c80, rs=rs@entry=0x7f7e5fff9c10) at result.c:508 #13 0x000056094a6dd11c in send_ldap_response (op=op@entry=0x7f7e5fff9c80, rs=rs@entry=0x7f7e5fff9c10) at result.c:583 #14 0x000056094a6ddd43 in slap_send_ldap_result (op=0x7f7e5fff9c80, rs=0x7f7e5fff9c10) at result.c:861 #15 0x000056094a7a86fd in mdb_add (op=0x7f7e5fff9c80, rs=0x7f7e5fff9c10) at add.c:435 #16 0x000056094a73cd78 in overlay_op_walk (op=op@entry=0x7f7e5fff9c80, rs=0x7f7e5fff9c10, which=op_add, oi=0x56094bb8a720, on=<optimized out>) at backover.c:677 #17 0x000056094a73ceab in over_op_func (op=0x7f7e5fff9c80, rs=<optimized out>, which=<optimized out>) at backover.c:730 #18 0x00007f7f5361ff6a in accesslog_response (op=<optimized out>, rs=<optimized out>) at accesslog.c:1877 #19 0x000056094a6dcb98 in slap_response_play (op=op@entry=0x7f7e7410fff0, rs=rs@entry=0x7f7e5fffa870) at result.c:508 #20 0x000056094a6dd11c in send_ldap_response (op=op@entry=0x7f7e7410fff0, rs=rs@entry=0x7f7e5fffa870) at result.c:583 #21 0x000056094a6ddd43 in slap_send_ldap_result (op=0x7f7e7410fff0, rs=0x7f7e5fffa870) at result.c:861 #22 0x000056094a7a86fd in mdb_add (op=0x7f7e7410fff0, rs=0x7f7e5fffa870) at add.c:435 #23 0x000056094a73cd78 in overlay_op_walk (op=op@entry=0x7f7e7410fff0, rs=0x7f7e5fffa870, which=op_add, oi=0x56094bb8a900, on=<optimized out>) at backover.c:677 #24 0x000056094a73ceab in over_op_func (op=0x7f7e7410fff0, rs=<optimized out>, which=<optimized out>) at backover.c:730 #25 0x000056094a6d32bd in fe_op_add (op=0x7f7e7410fff0, rs=0x7f7e5fffa870) at add.c:334 #26 0x000056094a6d4139 in do_add (op=0x7f7e7410fff0, rs=0x7f7e5fffa870) at add.c:194 #27 0x000056094a6cbfc0 in connection_operation (ctx=ctx@entry=0x7f7e5fffaab0, arg_v=arg_v@entry=0x7f7e7410fff0) at connection.c:1175 #28 0x000056094a6ccdbe in connection_read_thread (ctx=0x7f7e5fffaab0, argv=0x1a) at connection.c:1311 #29 0x00007f7f5903bead in ldap_int_thread_pool_wrapper (xpool=0x56094bb2a1d0) at tpool.c:696 #30 0x00007f7f57ae414a in start_thread () from /lib64/libpthread.so.0 #31 0x00007f7f57815f23 in clone () from /lib64/libc.so.6 If we take down the second node, we cannot reproduce the segfaults anymore. Let me know if we can provide more information (we can't provide the core dump since it's full of passwords). -- You are receiving this mail because: You are on the CC list for the issue.

1 19

[Issue 9419] New: Add support for HAProxy proxy protocol v2
by openldap-its＠openldap.org 15 Mar '21

15 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=9419 Issue ID: 9419 Summary: Add support for HAProxy proxy protocol v2 Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: henson(a)acm.org Target Milestone: --- Add support for the HAProxy proxy protocol v2: https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt This will allow slapd to receive and act upon client addresses when operating behind a NAT'ing load balancer or proxy server which would otherwise obscure the true client address. Patch will be submitted as a pull request on gitlab. The submitted pull request is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the pull request were developed by Paul B. Henson <henson(a)acm.org> based on specifications and example code provided by HAProxy at the above listed URL. I have not assigned rights and/or interest in this work to any party. The modifications to OpenLDAP Software are subject to the following notice: Copyright 2020 Paul B. Henson Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

← Newer
1
2
3
4
5
6
7
8
9
...
30
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2021