openldap-bugs June 2020

openldap-bugs@openldap.org

1 participants
196 discussions

[Issue 9274] New: sample-mdb.txt SIGSEGV
by openldap-its＠openldap.org 08 Jun '20

08 Jun '20

https://bugs.openldap.org/show_bug.cgi?id=9274 Issue ID: 9274 Summary: sample-mdb.txt SIGSEGV Product: LMDB Version: 0.9.22 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: txtoth(a)gmail.com Target Milestone: --- Running on centos7. Installed lmdb, lmdb-libs and lmdb-devel version … [View More]

1 2

[Issue 9273] New: Socket leak when RST is received from LDAP Server
by openldap-its＠openldap.org 08 Jun '20

08 Jun '20

https://bugs.openldap.org/show_bug.cgi?id=9273 Issue ID: 9273 Summary: Socket leak when RST is received from LDAP Server Product: OpenLDAP Version: 2.3 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: 30973971(a)qq.com Target Milestone: --- Hi I use OpenLDAP client for TLS … [View More]connections with the LDAP server. We see socket leak happens when Authenticating with LDAP Servers. From fd_end_480F.txt which monitors the fd open by our process, we can see 996/997/998/999 are new sockets lrwx------ 1 root root 64 May 27 17:37 996 -> socket:[2054679952] lrwx------ 1 root root 64 May 27 17:37 997 -> socket:[2054685915] lrwx------ 1 root root 64 May 27 17:37 998 -> socket:[2054677956] lrwx------ 1 root root 64 May 27 17:37 999 -> socket:[2054679950] Search 996 in strace_480F.txt, get these logs in the end of the search. 10.65.85.71 is the ip address of LDAP server. 4086 17:38:59 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 996 <0.000015> 4086 17:38:59 fcntl64(996, F_SETFD, FD_CLOEXEC) = 0 <0.000010> 4086 17:38:59 setsockopt(996, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0 <0.000011> 4086 17:38:59 setsockopt(996, SOL_TCP, TCP_NODELAY, [1], 4) = 0 <0.000011> 4086 17:38:59 fcntl64(996, F_GETFL) = 0x2 (flags O_RDWR) <0.000011> 4086 17:38:59 fcntl64(996, F_SETFL, O_RDWR|O_NONBLOCK) = 0 <0.000010> 4086 17:38:59 connect(996, {sa_family=AF_INET, sin_port=htons(636), sin_addr=inet_addr("10.65.85.71")}, 16) = -1 EINPROGRESS (Operation now in progress) <0.000028> 4086 17:38:59 poll([{fd=996, events=POLLOUT|POLLERR|POLLHUP}], 1, 5000) = 1 ([{fd=996, revents=POLLOUT}]) <0.000732> 4086 17:38:59 poll([{fd=996, events=POLLOUT|POLLERR|POLLHUP}], 1, 5000) = 1 ([{fd=996, revents=POLLOUT}]) <0.000732> 4086 17:38:59 getpeername(996, {sa_family=AF_INET, sin_port=htons(636), sin_addr=inet_addr("10.65.85.71")} , [16]) = 0 <0.000027> 4086 17:38:59 fcntl64(996, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK) <0.000025> 4086 17:38:59 fcntl64(996, F_SETFL, O_RDWR) = 0 <0.000025> 4086 17:38:59 write(996, "\26\3\3\0}\1\0\0y\3\3^\316\245\263OO\0\\A\254V\223\247S\267\230\3537\207\201C"..., 130) = 130 <0.000020> 4086 17:38:59 read(996, <unfinished ...> 4086 17:38:59 read(996, "\2\0\0M\3\3^\316\245\263\271\272z\2\222c_z\177t\347o<\204\333C\372+\\\322A\205"..., 4175) = 4175 <0.000013> 4086 17:38:59 getpeername(996, {sa_family=AF_INET, sin_port=htons(636), sin_addr=inet_addr("10.65.85.71")} , [16]) = 0 <0.000011> 4086 17:38:59 write(996, "\26\3\3\0\7\v\0\0\3\0\0\0\26\3\3\0\206\20\0\0\202\0\200\272\16\205^\261\314S\20\365"..., 202) = 202 <0.000023> 4086 17:38:59 read(996, <unfinished ...> 4086 17:38:59 read(996, "\1", 1) = 1 <0.000027> 4086 17:38:59 read(996, "\26\3\3\0(", 5) = 5 <0.000024> 4086 17:38:59 read(996, "\0\0\0\0\0\0\0\0\222\255$g\302\212\"\37\347\5\232\273g\376\326\367\274M^K\332\321\2077"..., 40) = 40 <0.000025> 4086 17:38:59 write(996, "\26\3\3\0\242\1\0\0\236\3\3^\316\245\263\337\20\223cX\326\255U\352\374\207\t\36776G\316"..., 167) = 167 <0.000016> 4086 17:38:59 read(996, 0xac2189b, 5) = -1 ECONNRESET (Connection reset by peer) <0.001126> Receive ECONNRESET when do read(996), but didn't see close(996) after read(996) 996 was closed when a subprocess is created (subprocess and parent process share the handle, this mean 996 is still open at 17:39) 15716 17:39:00 close(996) = 0 <0.000011> 4081 17:39:00 <... vfork resumed> ) = 15716 <0.042404> 996 was closed when another subprocess is created (subprocess and parent process share the same handle, this means that 996 is still open at 17:44) 330 17:44:00 close(996) = 0 <0.000011> 330 17:44:00 execve("/nas/http/scripts/MOD_SEC/getcas", ["/nas/http/scripts/Mod_SEC/ge"..., "-type", "logout", "-host", "22.126.26.10", "-server_name", "22.126.26.10", "-scheme", "https", "-local", "true"], [/* 147 vars */] <unfinished ...> 4084 17:44:00 <... vfork resumed> ) = 330 <0.039188> Would you please let me know if this a known issue or a bug? -- You are receiving this mail because: You are on the CC list for the issue. [View Less]

1 2

[Issue 7958] LMDB: LIFO-reclaiming, write-performance improvement & bugfixes
by openldap-its＠openldap.org 08 Jun '20

08 Jun '20

https://bugs.openldap.org/show_bug.cgi?id=7958 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 7958] LMDB: LIFO-reclaiming, write-performance improvement & bugfixes
by openldap-its＠openldap.org 07 Jun '20

07 Jun '20

https://bugs.openldap.org/show_bug.cgi?id=7958 Leonid Yuriev <leo(a)yuriev.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #7 from Leonid Yuriev <leo(a)yuriev.ru> --- MDBX_LIFORECLAIM implemented & checked in the libmdbx project. -- You are receiving … [View More]

1 0

[Issue 8610] ldaps not usable with DNS SRV
by openldap-its＠openldap.org 06 Jun '20

06 Jun '20

https://bugs.openldap.org/show_bug.cgi?id=8610 --- Comment #4 from Michael Ströder <michael(a)stroeder.com> --- And still there is no standard which defines a decent TLS domain name check for SRV RRs with well-defined subjectAltName values to prevent MITM attacks. See also: https://tools.ietf.org/html/rfc6125#section-3 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8610] ldaps not usable with DNS SRV
by openldap-its＠openldap.org 05 Jun '20

05 Jun '20

https://bugs.openldap.org/show_bug.cgi?id=8610 --- Comment #3 from braiamp(a)gmail.com --- Also present on Debian version ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.50+dfsg-1 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8610] ldaps not usable with DNS SRV
by openldap-its＠openldap.org 05 Jun '20

05 Jun '20

https://bugs.openldap.org/show_bug.cgi?id=8610 --- Comment #2 from braiamp(a)gmail.com --- This issue seem to be still present in master. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5974] libldap not consistently using namespaces
by openldap-its＠openldap.org 04 Jun '20

04 Jun '20

1 0

[Issue 8608] slapo-pcache: Inversion in filter pcacheTemplate cannot be parsed
by openldap-its＠openldap.org 04 Jun '20

04 Jun '20

1 0

[Issue 8608] slapo-pcache: Inversion in filter pcacheTemplate cannot be parsed
by openldap-its＠openldap.org 04 Jun '20

04 Jun '20

https://bugs.openldap.org/show_bug.cgi?id=8608 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Howard Chu <hyc(a)openldap.org> --- This feature works as designed. Read the ProxyCache design paper for details. https://… [View More]

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2020