openldap-bugs

openldap-bugs@openldap.org

1 participants
20891 discussions

[Issue 7777] Filtering on modifyTimestamp is slower with index
by openldap-its＠openldap.org 23 Oct '23

23 Oct '23

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

1 0

[Issue 7777] Filtering on modifyTimestamp is slower with index
by openldap-its＠openldap.org 23 Oct '23

23 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=7777 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |SUSPENDED Target Milestone|2.7.0 |--- --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- patches welcome generally don't index timestamps. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10114] New: Crash in mdb_copy with stale transactions(?)
by openldap-its＠openldap.org 23 Oct '23

23 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10114 Issue ID: 10114 Summary: Crash in mdb_copy with stale transactions(?) Product: LMDB Version: 0.9.30 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: zack+ldapbugs(a)owlfolio.org Target Milestone: --- I have a LMDB database which is damaged in some way, I'm not sure exactly how, but the application that created it (KDE baloo_file) crashes on startup while trying to read it, with a backtrace pointing inside liblmdb... #0 __memcpy_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:837 #1 0x00007fbf1fa110b6 in mdb_page_touch (mc=mc@entry=0x7ffe8dc1adf0) at mdb.c:2502 #2 0x00007fbf1fa12c9c in mdb_cursor_touch (mc=mc@entry=0x7ffe8dc1adf0) at mdb.c:6563 #3 0x00007fbf1fa16228 in mdb_cursor_put (mc=mc@entry=0x7ffe8dc1adf0, key=key@entry=0x7ffe8dc1b1e0, data=data@entry=0x7ffe8dc1b1f0, flags=<optimized out>, flags@entry=0) at mdb.c:6697 #4 0x00007fbf1fa18d51 in mdb_put (txn=0x55986d167a70, dbi=<optimized out>, key=0x7ffe8dc1b1e0, data=0x7ffe8dc1b1f0, flags=0) at mdb.c:9076 #5 0x00007fbf1fcec44b in Baloo::PostingDB::put (this=this@entry=0x7ffe8dc1b2d0, term=..., list=...) at /usr/src/debug/kde-frameworks/baloo-5.110.0/baloo-5.110.0/src/engine/postingdb.cpp:66 If I try to mdb_dump the database (with nothing else trying to access it) I get mdb_dump: index: MDB_BAD_TXN: Transaction must abort, has a child, or is invalid That sounds like the sort of thing that ought to be cleared by mdb_copy -c, but instead that command also crashes inside __memcpy_avx_unaligned_erms. Backtrace: #0 __memcpy_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:839 #1 0x0000555555557e67 in mdb_env_cwalk (my=my@entry=0x7fffffffdbc0, pg=pg@entry=0x7fffffffd988, flags=0) at mdb.c:9264 #2 0x0000555555557fdf in mdb_env_cwalk (my=my@entry=0x7fffffffdbc0, pg=pg@entry=0x7fffffffdb90, flags=flags@entry=0) at mdb.c:9306 #3 0x0000555555558523 in mdb_env_copyfd1 (env=0x55555556a2a0, fd=<optimized out>) at mdb.c:9469 #4 0x00005555555588c9 in mdb_env_copy2 (env=0x55555556a2a0, path=<optimized out>, flags=flags@entry=1) at mdb.c:9623 #5 0x0000555555558ea6 in main (argc=3, argv=0x7fffffffe008) at mdb_copy.c:74 I tried to poke at the offending data structure a little but I didn't immediately see what was wrong... (gdb) frame 1 #1 0x0000555555557e67 in mdb_env_cwalk (my=my@entry=0x7fffffffdbc0, pg=pg@entry=0x7fffffffd988, flags=0) at mdb.c:9264 9264 mdb_page_copy(leaf, mp, my->mc_env->me_psize); (gdb) p mp $1 = (MDB_page *) 0x7fc008d32000 (gdb) p *mp $2 = {mp_p = {p_pgno = 0x0606060606060606, p_next = 0x0606060606060606}, mp_pad = 1542, mp_flags = 1542, mp_pb = {pb = {pb_lower = 1542, pb_upper = 18832}, pb_pages = 1234175494}, mp_ptrs = 0x7fc008d32010} ... except that those values for p_pgno and p_next don't look terribly plausible to me. The database file is, unfortunately, much too large to attach here (2.3G uncompressed, 383M compressed with xz -17) and also it's, well, a full-text index of everything I have on my computer, so I'd be hesitant to attach it even if it fit. I can make it available for private download if that would be helpful. I'm also happy to do other experiments. I realize that crashes caused by database corruption can be very difficult to avoid but I hope there might be some kind of easy defensive measure to take in this particular case which could at least allow the application to fail cleanly rather than crashing. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10113] New: make connection debug output more uniform
by openldap-its＠openldap.org 23 Oct '23

23 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10113 Issue ID: 10113 Summary: make connection debug output more uniform Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: enhancement Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Here's what some of the debug output looks like currently: 6529a16e.07884bd6 0x7f7a68dff640 daemon: epoll: listen=8 active_threads=0 tvp=NULL 6529a16e.0788551d 0x7f7a68dff640 daemon: activity on 1 descriptor 6529a16e.07885e63 0x7f7a68dff640 daemon: activity on:6529a16e.07886607 0x7f7a68dff640 6529a16e.07886f93 0x7f7a68dff640 daemon: epoll: listen=7 active_threads=0 tvp=NULL 6529a16e.07887737 0x7f7a68dff640 daemon: epoll: listen=8 active_threads=0 tvp=NULL 6529a16e.0788987f 0x7f7a63fff640 tls_write: want=239 error=Broken pipe 6529a16e.0788a369 0x7f7a63fff640 TLS trace: SSL_accept:SSLv3/TLS write session ticket 6529a16e.0788d027 0x7f7a63fff640 connection_read(12): unable to get TLS client DN, error=49 id=1000 6529a16e.0788e6cc 0x7f7a63fff640 conn=1000 fd=12 TLS established tls_ssf=128 ssf=128 tls_proto=TLSv1.3 tls_cipher=TLS_AES_128_GCM_SHA256 6529a16e.078974a9 0x7f7a68dff640 daemon: activity on 2 descriptors 6529a16e.07898cf1 0x7f7a68dff640 daemon: activity on:6529a16e.07899409 0x7f7a68dff640 12r6529a16e.07899ef3 0x7f7a68dff640 6529a16e.0789a839 0x7f7a68dff640 daemon: read active on 12 6529a16e.0789c1de 0x7f7a68dff640 daemon: epoll: listen=7 active_threads=0 tvp=NULL 6529a16e.0789cd0e 0x7f7a68dff640 daemon: epoll: listen=8 active_threads=0 tvp=NULL 6529a16e.0789d9e0 0x7f7a68dff640 daemon: activity on 1 descriptor 6529a16e.0789e36d 0x7f7a68dff640 daemon: activity on:6529a16e.0789eaca 0x7f7a68dff640 6529a16e.0789f26e 0x7f7a68dff640 daemon: epoll: listen=7 active_threads=0 tvp=NULL 6529a16e.0789fd9d 0x7f7a68dff640 daemon: epoll: listen=8 active_threads=0 tvp=NULL 6529a16e.078a0a70 0x7f7a63fff640 connection_get(12) 6529a16e.078a1ea0 0x7f7a63fff640 connection_get(12): got connid=1000 6529a16e.078a25b8 0x7f7a63fff640 connection_read(12): checking for input on id=1000 6529a16e.078a32d0 0x7f7a63fff640 ber_get_next 6529a16e.078a6a78 0x7f7a63fff640 tls_read: want=5, got=5 6529a16e.078a7d91 0x7f7a63fff640 0000: 30 05 02 01 02 0.... 6529a16e.078aa0c2 0x7f7a63fff640 tls_write: want=24 error=Broken pipe 6529a16e.078aa820 0x7f7a63fff640 ldap_read: want=8 error=Broken pipe 6529a16e.078ab121 0x7f7a63fff640 ber_get_next on fd 12 failed errno=32 (Broken pipe) 6529a16e.078aba67 0x7f7a63fff640 connection_read(12): input error=-2 id=1000, closing. 6529a16e.078ac3ae 0x7f7a63fff640 connection_closing: readying conn=1000 sd=12 for close 6529a16e.078ad0c6 0x7f7a63fff640 connection_close: conn=1000 sd=12 6529a16e.078aed26 0x7f7a63fff640 daemon: removing 12 6529a16e.078b2ffd 0x7f7a68dff640 daemon: activity on 1 descriptor 6529a16e.078b4616 0x7f7a63fff640 conn=1000 fd=12 closed (connection lost) Most operations will be logged with "conn=xxxx fd=yy blah blah" but things like connection_close etc log "blah blah conn=xxxx sd=yy" instead. It would be nice if they all uniformly started with "conn=xxxx fd=yy blah blah" This is a trivial change. Could be a good first-time commit for a new dev. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 10120] New: slapd crashes when changing ARGON2 olcRootPW via ldapmodify
by openldap-its＠openldap.org 23 Oct '23

23 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10120 Issue ID: 10120 Summary: slapd crashes when changing ARGON2 olcRootPW via ldapmodify Product: OpenLDAP Version: 2.6.5 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: aimass(a)yabarana.com Target Milestone: --- slapd dies when executing LDIF remotely with ldapmodify: This is the command we are running: ldapadd -H ldap://:xxx -x -D xxx -w xxx -f foo.ldif (we are using ldapadd as a convenience because the LDIF file creates and modifies entries) This fragment of foo.ldif causes slapd to die: dn: olcDatabase={0}config,cn=config changetype: modify replace: olcRootPW olcRootPW: {ARGON2}$argon2id$v=19$m=65536,t=128,p=2$******** The last few lines of debug indicate this: 2023-10-23 15:49:36 653679f0.32572d8b 0xffff45945b10 mdb_idl_insert_keys: 56 [f8bb395f] 2023-10-23 15:49:36 653679f0.325f95ba 0xffff45945b10 send_ldap_result: err=0 matched="" text="" 2023-10-23 15:49:36 653679f0.3266665b 0xffff46249b10 connection_get(13) 2023-10-23 15:49:36 653679f0.3266bebc 0xffff46249b10 conn=1010 op=2 do_modify: dn (olcDatabase={0}config,cn=config) 2023-10-23 15:49:36 653679f0.3266c8a9 0xffff46249b10 => ldap_bv2dn(olcDatabase={0}config,cn=config,0) 2023-10-23 15:49:36 653679f0.3266d026 0xffff46249b10 <= ldap_bv2dn(olcDatabase={0}config,cn=config)=0 2023-10-23 15:49:36 653679f0.3266e35b 0xffff46249b10 => ldap_dn2bv(272) 2023-10-23 15:49:36 653679f0.32671cf9 0xffff46249b10 <= ldap_dn2bv(olcDatabase={0}config,cn=config)=0 2023-10-23 15:49:36 653679f0.326723a5 0xffff46249b10 => ldap_dn2bv(272) 2023-10-23 15:49:36 653679f0.32672904 0xffff46249b10 <= ldap_dn2bv(olcDatabase={0}config,cn=config)=0 2023-10-23 15:49:36 653679f0.32672e63 0xffff46249b10 conn=1010 op=2 modifications: 2023-10-23 15:49:36 653679f0.326803c4 0xffff46249b10 replace: olcRootPW 2023-10-23 15:49:36 653679f0.32681a3a 0xffff46249b10 one value, length 384 2023-10-23 15:49:36 Assertion failed: pool->ltp_pause == PAUSED (tpool.c: ldap_pvt_thread_pool_resume: 1319) -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10119] New: log function do NOT work.
by openldap-its＠openldap.org 22 Oct '23

22 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10119 Issue ID: 10119 Summary: log function do NOT work. Product: OpenLDAP Version: 2.5.13 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: 142857uk(a)gmail.com Target Milestone: --- The logging function of this version of `slapd` seems not working at all. The configuration of `slapd` is as follow : ``` dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcLogFile: /tmp/slapd.log olcLogLevel: -1 olcPidFile: /var/run/slapd/slapd.pid olcToolThreads: 1 ``` I set `olcLogLevel` to -1 to enable logging everything. Other values to `olcLogLevel` like 256, 4 were already tested, not working. So stop shitting about this direction. I use `tail` to monitor the content of `/tmp/slapd.log`, nothing! I also checked the permission of `openldap` user on `/tmp/slapd.log`, and it does have the right to write to it. So, shut the fuck up about this direction. Am I like a newbee? My question is, why can't a soooooooo simple function like logging work? Did you guys bother testing it at all before you release your fucking software? I try to be civilization, but you bitches just don't deserve it. Sorry to say that but unfortunately it's a fact. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10118] New: slapcat terminates with "double free or corruption (out)" message
by openldap-its＠openldap.org 21 Oct '23

21 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=10118 Issue ID: 10118 Summary: slapcat terminates with "double free or corruption (out)" message Product: OpenLDAP Version: 2.5.13 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: dma_k(a)mail.ru Target Milestone: --- The issue started to appear after upgrading slapd from v2.4.57 to v2.5.13 (Debian bullseye → bookworm). $ slapcat -s cn=config ... double free or corruption (out) Aborted (core dumped) Coredump: #0 0x00007faf0a009d3c n/a (libc.so.6 + 0x8ad3c) #1 0x00007faf09fbaf32 raise (libc.so.6 + 0x3bf32) #2 0x00007faf09fa5472 abort (libc.so.6 + 0x26472) #3 0x00007faf09ffe340 n/a (libc.so.6 + 0x7f340) #4 0x00007faf0a0136ba n/a (libc.so.6 + 0x946ba) #5 0x00007faf0a015720 n/a (libc.so.6 + 0x96720) #6 0x00007faf0a017d9f __libc_free (libc.so.6 + 0x98d9f) #7 0x00005608e5287216 slap_tool_init (slapcat + 0xba216) #8 0x00005608e52864a1 slapcat (slapcat + 0xb94a1) #9 0x00005608e51edc73 main (slapcat + 0x20c73) #10 0x00007faf09fa61ca n/a (libc.so.6 + 0x271ca) #11 0x00007faf09fa6285 __libc_start_main (libc.so.6 + 0x27285) #12 0x00005608e51ef061 _start (slapcat + 0x22061) -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9936] New: slapd attempting free on address which was not malloced
by openldap-its＠openldap.org 20 Oct '23

20 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=9936 Issue ID: 9936 Summary: slapd attempting free on address which was not malloced Product: OpenLDAP Version: 2.6.3 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: kimjuhi96(a)snu.ac.kr Target Milestone: --- I get invalid free running this on the latest openldap from git, built with CFLAGS="-fsanitize=address" using clang 15. Seems this is similar to https://bugs.openldap.org/show_bug.cgi?id=9912. ./servers/slapd/slapd -T c -s1 -s1 Stopped reason: SIGABRT __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. gdb-peda$ bt #0 __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007ffff78ca859 in __GI_abort () at abort.c:79 #2 0x00005555556eb04f in __sanitizer::Abort () at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_posix_libcdep.cpp:143 #3 0x00005555556e8aac in __sanitizer::Die () at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_termination.cpp:58 #4 0x00005555556c5dda in __asan::ScopedInErrorReport::~ScopedInErrorReport (this=0x7fffffffbe7e, __in_chrg=<optimized out>) at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/asan_report.cpp:192 #5 0x00005555556c72b8 in __asan::ReportFreeNotMalloced (addr=<optimized out>, free_stack=0x7fffffffca90) at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/asan_report.cpp:199 #6 0x00005555556c02ab in __interceptor_free (ptr=0x7fffffffe359) at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:53 #7 0x0000555555d3efe2 in ber_memfree_x () #8 0x0000555555847d33 in ch_free () #9 0x0000555555a31178 in slap_tool_init () #10 0x0000555555a2e54d in slapcat () #11 0x000055555570901f in main () #12 0x00007ffff78cc083 in __libc_start_main (main=0x555555706ef0 <main>, argc=0x5, argv=0x7fffffffdfc8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdfb8) at ../csu/libc-start.c:308 #13 0x000055555561011e in _start () at /home/juhee/project/foxfuzz/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_internal_defs.h:397 gdb-peda$ -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10116] Use-After-Free (CWE-416)
by openldap-its＠openldap.org 19 Oct '23

19 Oct '23

1 0

[Issue 9888] New: When using cn=config replication, schema updates can corrupt the index database(s)
by openldap-its＠openldap.org 19 Oct '23

19 Oct '23

https://bugs.openldap.org/show_bug.cgi?id=9888 Issue ID: 9888 Summary: When using cn=config replication, schema updates can corrupt the index database(s) Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Today I pushed a schema update out to the config node that holds schema that is replicated to the providers and consumers. Post schema update, 2/11 servers crashed in the mdb online indexing function. I fixed this by slapcat the db and slapadd the db. This is important because it was later revealed that on the 9/11 servers that did not crash or have their database reloaded, ldapsearch would return the wrong attribute names for some attribute:value pairs in the database, which caused mayhem in downstream systems and caused replication issues between the nodes. The 2 nodes that were reloaded immediately after the schema change had the only "good" copies of the database left. To give an example, say an entry was something like: dn: uid=joe,ou=people,dc=example,dc=com uid: joe sn: smith cn: joe smith givenName: joe After the change, the broken servers could return something like: dn: uid=joe,ou=people,dc=example,dc=com uid: joe posixGroup: smith cn: joe smith givenName joe It's not clear how deeply this bug ran in the database. It for sure affected 2 attributes used by the person objectClass. Both of the "replacement" attributes were not valid attributes for the person objectClasses in use. Maybe related to the changes in ITS#9858? -- You are receiving this mail because: You are on the CC list for the issue.

1 19

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs