- openldap-bugs - openldap.org

[Issue 8603] [PATCH] adds ldif_open_mem()
by openldap-its＠openldap.org 10 Jun '20

10 Jun '20

https://bugs.openldap.org/show_bug.cgi?id=8603 --- Comment #4 from brett(a)gladserv.com <brett(a)gladserv.com> --- Thanks Quanah. """ Copyright 2014, 2017 Brett Sheffield Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. I have not assigned rights and/or interest in this work to any party. """ https://www.openldap.org/devel/contributing.html#notice On 2020-06-10 15:15, openldap-its(a)openldap.org wrote: > https://bugs.openldap.org/show_bug.cgi?id=8603 > > --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- > Hi Brett, > > Thanks for the contribution. However it is missing an appropriate assignment > of rights statement as noted at > https://www.openldap.org/devel/contributing.html#notice > > If you can add such a statement to this ITS that would be appreciated. > > Regards, > Quanah > > -- > You are receiving this mail because: > You reported the issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8140] ssf is hard coded to log as zero, even if it is non-zero
by openldap-its＠openldap.org 10 Jun '20

10 Jun '20

1 0

[Issue 8603] [PATCH] adds ldif_open_mem()
by openldap-its＠openldap.org 10 Jun '20

10 Jun '20

https://bugs.openldap.org/show_bug.cgi?id=8603 --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Hi Brett, Thanks for the contribution. However it is missing an appropriate assignment of rights statement as noted at https://www.openldap.org/devel/contributing.html#notice If you can add such a statement to this ITS that would be appreciated. Regards, Quanah -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8434] Config entry cleanup on Add should be run unconditionally
by openldap-its＠openldap.org 10 Jun '20

10 Jun '20

https://bugs.openldap.org/show_bug.cgi?id=8434 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |IN_PROGRESS --- Comment #3 from Ondřej Kuzník <ondra(a)mistotebe.net> --- Code to implement this is in a merge request here: https://git.openldap.org/openldap/openldap/-/merge_requests/79 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[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 0.9.22-2 from the EPEL repo. Copied code from: https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/sample-mdb.t… Compiled: gcc -g -o sample-mdb -llmdb sample-mdb.c gdb sample-mdb (gdb) r Program received signal SIGSEGV, Segmentation fault. 0x00007ffff79c2d91 in mdb_txn_renew0 () from /lib64/liblmdb.so.0.0.0 (gdb) where #0 0x00007ffff79c2d91 in mdb_txn_renew0 () from /lib64/liblmdb.so.0.0.0 #1 0x00007ffff79c4454 in mdb_txn_begin () from /lib64/liblmdb.so.0.0.0 #2 0x0000000000400b29 in main (argc=1, argv=0x7fffffffe0d8) at sample-mdb.c:34 (gdb) -- You are receiving this mail because: You are on the CC list for the issue.

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 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.

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 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 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://openldap.org/conf/odd-wien-2003/proceedings.html -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8473] unkown plugin type {0} preoperation
by openldap-its＠openldap.org 04 Jun '20

04 Jun '20

https://bugs.openldap.org/show_bug.cgi?id=8473 --- Comment #2 from Ondřej Kuzník <ondra(a)mistotebe.net> --- Merge request to fix this has been proposed: https://git.openldap.org/openldap/openldap/-/merge_requests/78 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9051] slapo-accesslog fails to log compare, search
by openldap-its＠openldap.org 04 Jun '20

04 Jun '20

https://bugs.openldap.org/show_bug.cgi?id=9051 --- Comment #2 from Ondřej Kuzník <ondra(a)mistotebe.net> --- Can't reproduce this in master or re24... Compares don't get logged if logsuccess is on, that should probably be fixed (including COMPARE_{TRUE,FALSE} and SASL_BIND_IN_PROGRESS as successes?) Needs more information? This is the minimal config where everything works (replace $ops accordingly): database null suffix cn=test rootdn cn=test rootpw pass overlay accesslog logdb cn=log logops $ops logsuccess off database mdb directory ./db suffix cn=log rootdn cn=test overlay syncprov -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8143] SegV in ~LDAPCtrl()
by openldap-its＠openldap.org 04 Jun '20

04 Jun '20

https://bugs.openldap.org/show_bug.cgi?id=8143 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|slapd |libraries -- 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

https://bugs.openldap.org/show_bug.cgi?id=5974 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #7 from Ondřej Kuzník <ondra(a)mistotebe.net> --- None of this applies to libldap(_r)/liblber in master anymore. Nor does slapd seem to reference ldap_int_* symbols directly. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8768] Syncprov shouldn't send a new cookie at the end of delete phase
by openldap-its＠openldap.org 04 Jun '20

04 Jun '20

https://bugs.openldap.org/show_bug.cgi?id=8768 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |IN_PROGRESS --- Comment #5 from Ondřej Kuzník <ondra(a)mistotebe.net> --- https://git.openldap.org/openldap/openldap/-/merge_requests/4 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6467] syncrepl enhancements
by openldap-its＠openldap.org 04 Jun '20

04 Jun '20

https://bugs.openldap.org/show_bug.cgi?id=6467 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |IN_PROGRESS Depends on| |8768 --- Comment #5 from Ondřej Kuzník <ondra(a)mistotebe.net> --- Code to implement this is in a merge request here: https://git.openldap.org/openldap/openldap/-/merge_requests/5 Referenced Issues: https://bugs.openldap.org/show_bug.cgi?id=8768 [Issue 8768] Syncprov shouldn't send a new cookie at the end of delete phase -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8768] Syncprov shouldn't send a new cookie at the end of delete phase
by openldap-its＠openldap.org 04 Jun '20

04 Jun '20

https://bugs.openldap.org/show_bug.cgi?id=8768 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |6467 Referenced Issues: https://bugs.openldap.org/show_bug.cgi?id=6467 [Issue 6467] syncrepl enhancements -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6207] Build farm
by openldap-its＠openldap.org 04 Jun '20

04 Jun '20

https://bugs.openldap.org/show_bug.cgi?id=6207 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|ondra(a)mistotebe.net |bugs(a)openldap.org -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8182] setspec matching fails unexpectedly
by openldap-its＠openldap.org 03 Jun '20

03 Jun '20

https://bugs.openldap.org/show_bug.cgi?id=8182 --- Comment #2 from Ondřej Kuzník <ondra(a)mistotebe.net> --- Dealing with this would need access to the attribute type in the other set we're joining with so the literal 'canBrowse' could be normalised accordingly. But the way set ACLs are parsed at the moment, there is no way to keep and propagate this information. We might have to turn to a parser generator to get an AST and annotate accordingly if this is needed. That would in turn make us require YACC or whatever we chose. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7089] ppolicy adds PWDFAILURETIME to organizationalUnit
by openldap-its＠openldap.org 03 Jun '20

03 Jun '20

https://bugs.openldap.org/show_bug.cgi?id=7089 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |IN_PROGRESS --- Comment #7 from Ondřej Kuzník <ondra(a)mistotebe.net> --- I have created a patchset that attempts to address this and other ppolicy related issues here: https://git.openldap.org/openldap/openldap/-/merge_requests/77 Please review, test and let me know if this addresses the issue and if you have any other comments. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8762] Unlocking an account doesn't remove pwdFailureTime
by openldap-its＠openldap.org 03 Jun '20

03 Jun '20

https://bugs.openldap.org/show_bug.cgi?id=8762 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |IN_PROGRESS --- Comment #10 from Ondřej Kuzník <ondra(a)mistotebe.net> --- I have created a patchset that attempts to address this and other ppolicy related issues here: https://git.openldap.org/openldap/openldap/-/merge_requests/77 Please review, test and let me know if this addresses the issue and if you have any other comments. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs