https://bugs.openldap.org/show_bug.cgi?id=9620
Issue ID: 9620
Summary: back-monitor: search can access a persistent entry
freed in the meantime
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
With ITS#9600 there is now code that adds and removes "persistent" monitor
entries outside a server pause. A concurrent cn=monitor search lists all
children first and sends them later - monitor is happy to free some of them in
the meantime.
It seems to me that the monitor cache should be protected by a rw mutex
instead, which would be held for reading while a search is happening.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9826
Issue ID: 9826
Summary: Openldap process stopped due to the 'segmentation
fault'
Product: OpenLDAP
Version: 2.4.59
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: rekha.shivsan(a)gmail.com
Target Milestone: ---
Created attachment 892
--> https://bugs.openldap.org/attachment.cgi?id=892&action=edit
kernel logs with segmentation fault error
Openldap process stopped due to the 'segmentation fault'. We have openldap
process running as a service.
/var/log/kern.log
Mar 6 11:15:01 ip-x-x-x-x kernel: show_signal_msg: 48 callbacks suppressed
Mar 6 11:15:01 ip-x-x-x-x kernel: slapd[8778]: segfault at 8 ip
00000000004afcc6 sp 00007fae42ffd400 error 4 in slapd[400000+130000]
/var/log/daemon.log
Mar 6 11:15:01 ip-x-x-x-xopenldap: 622497b5 connection_read(13): input
error=-2 id=19912, closing.
Mar 6 11:15:01 ip-x-x-x-xopenldap: 622497b5 connection_closing: readying
conn=19912 sd=13 for close
Mar 6 11:15:01 ip-x-x-x-xsystemd: openldap.service: main process exited,
code=killed, status=11/SEGV
Mar 6 11:15:01 ip-x-x-x-xsystemd: Unit openldap.service entered failed state.
Mar 6 11:15:01 ip-x-x-x-xsystemd: openldap.service failed.
If we restart the service, it runs fine for few days and again segmentation
fault is seen in kernel logs and the service gets stopped.
Please help us to resolve this issue.
Thanks
Rekha.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9784
Issue ID: 9784
Summary: Adding our OpenLDAP support services
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: contact(a)linuxstans.com
Target Milestone: ---
Hi,
We offer OpenLDAP support and we'd really appreciate it if you can add our
details to your support page https://www.openldap.org/support/
Here are the details:
<a href="https://linuxstans.com/support/">Linux Stans</a> - USA
Provides installation, configuration, maintenance, and 24/7 support services
for OpenLDAP.
Let me know if you need more info.
Thanks!
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9819
Issue ID: 9819
Summary: Bump version of ldapc++
Product: OpenLDAP
Version: 2.6.1
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: jengelh(a)inai.de
Target Milestone: ---
In the *SUSE family of Linux distributions, we have had a standalone ldapcpp
package, the code of which was authored by R. Haferkamp; the package is marked
0.3.1 inside and out and uses SONAME=libldapcpp.so.1. This ldapcpp package is
being phased out in favor of building the software from the copy in
openldap/contrib/ldapc++, which I find is also by Haferkamp. However, it is
marked as 0.0.0 and uses SONAME=libldapcpp.so.0.
----
» abidiff /usr/lib64/libldapcpp.so.1 .libs/libldapcpp.so.0
ELF SONAME changed
Functions changes summary: 0 Removed, 4 Changed, 2 Added (30 filtered out)
functions
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
Function symbols changes summary: 0 Removed, 9 Added function symbols not
referenced by debug info
Variable symbols changes summary: 0 Removed, 1 Added variable symbol not
referenced by debug info
SONAME changed from 'libldapcpp.so.1' to 'libldapcpp.so.0'
2 Added functions:
[A] 'method virtual LDAPMsg::~LDAPMsg(int)' {_ZN7LDAPMsgD0Ev}
note that this adds a new entry to the vtable of class LDAPMsg
[A] 'method virtual LDAPMsg::~LDAPMsg(int)' {_ZN7LDAPMsgD2Ev, aliases
_ZN7LDAPMsgD1Ev}
note that this adds a new entry to the vtable of class LDAPMsg
4 functions with some indirect sub-type change:
[C] 'method void LDAPAsynConnection::unbind()' at
LDAPAsynConnection.cpp:270:1 has some indirect sub-type changes:
parameter 1 of type 'int' was added
[C] 'method LDAPAttrType::LDAPAttrType()' at LDAPAttrType.cpp:11:1 has some
indirect sub-type changes:
parameter 1 of type 'int' was added
[C] 'method LDAPAttributeList::LDAPAttributeList()' at
LDAPAttributeList.cpp:24:1 has some indirect sub-type changes:
parameter 1 of type 'int' was added
[C] 'method LDAPSchema::LDAPSchema()' at LDAPSchema.cpp:18:1 has some
indirect sub-type changes:
parameter 1 of type 'int' was added
9 Added function symbols not referenced by debug info:
[A] _ZN12LDAPAttrTypeC1ERKS_
[A] _ZN12LDAPAttrTypeC2ERKS_, aliases _ZN12LDAPAttrTypeC1ERKS_
[A] _ZN13LDAPExceptionC1ERKS_, aliases _ZN13LDAPExceptionC2ERKS_
[A] _ZN13LDAPExceptionC2ERKS_
[A] _ZN16LDAPUrlExceptionD1Ev
[A] _ZN16LDAPUrlExceptionD2Ev, aliases _ZN16LDAPUrlExceptionD1Ev
[A] _ZNSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEED0Ev
[A] _ZNSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEED1Ev, aliases
_ZNSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEED2Ev
[A] _ZNSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEED2Ev
1 Added variable symbol not referenced by debug info:
[A] _ZTV7LDAPMsg
----
This leads me to believe that contrib/ldapc++ is actually the newer one despite
the inferior versioning.
To avoid confusion going forward, I propose to bump the version (in the
`version.var` file) to at least 0.3.1, and the SONAME should be changed to
libldapcpp.so.2 (now), so that future maintainers won't accidentally reuse
libldapcpp.so.1.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8143
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=7806
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7806
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=8143
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9821
Issue ID: 9821
Summary: slapo-homedir.5 is installed despite --disable-homedir
Product: OpenLDAP
Version: 2.6.1
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: michael(a)stroeder.com
Target Milestone: ---
Even with ./configure --disable-homedir the man page file slapo-homedir.5 is
installed.
Worth to fix this for 2.6.2?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9812
Issue ID: 9812
Summary: Registered SLAPI plugin functions are not called
Product: OpenLDAP
Version: 2.6.1
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: guru(a)unixarea.de
Target Milestone: ---
We're running since ages with an OpenLDAP server 2.4.40 a plugin which
publishes
changes (add, modify, delete) in LDAP to an Identity Server (IDM). We compile
on SuSE Linux from source. The configure options for 2.6.1 are:
./configure --enable-aci=yes --enable-dynacl --enable-spasswd=yes
--enable-crypt=yes --enable-debug=yes --enable-shared=yes --enable-modules=yes
--enable-slapi --enable-slapd=yes --with-tls --prefix=/opt/openldap-2.6.1
Our SLAPI plugin, written in C works fine for 2.4.40 and stopped working for
2.6.1. It is configured in slapd.conf as
plugin postoperation /opt/openldap-2.6.1/lib64/idm.so idm_init "IDM Plugin"
10.23.33.52 3001
The function idm_init() registers static C functions the supposed way:
int idm_init(Slapi_PBlock * pb)
{
int rc = LDAP_SUCCESS;
log("idm-plugin:","now in idm_init()\n");
// first call, create new list and register the functions
...
rc |=
slapi_pblock_set( /* Plug-in API version */ pb,
SLAPI_PLUGIN_VERSION,
SLAPI_PLUGIN_CURRENT_VERSION);
rc |=
slapi_pblock_set( /* Plug-in description */ pb,
SLAPI_PLUGIN_DESCRIPTION, (void *) &desc);
rc |=
slapi_pblock_set( /* Modify function */ pb,
SLAPI_PLUGIN_POST_MODIFY_FN,
(void *) modify_user);
...
// read arguments and add list entry
rc |= read_arguments(pb);
log("idm-plugin", "idm_init() return rc:%d\n", rc);
return rc;
}
The begin of the function for modify_user() looks like this:
static int modify_user(Slapi_PBlock * pb)
{
Slapi_Entry *entry;
log("idm-plugin:", "now in modify_user\n");
if (slapi_pblock_get(pb, SLAPI_SEARCH_TARGET, &entry) != LDAP_SUCCESS) {
log("IDM-Connector Plugin",
"entry modified, but couldn't get entry");
return -1;
}
...
But the function gets never called from slapd on changes in LDAP. The log shows
only the registering:
03/16/22 10:52:26 idm-plugin:: now in idm_init()
03/16/22 10:52:26 IDM-Connector Plugin: idm_init: Initializing plugin
03/16/22 10:52:26 idm-plugin:: now in read_arguments()
03/16/22 10:52:26 IDM Plugin: added idm connector: ip=10.23.33.52, port=3001
03/16/22 10:52:26 idm-plugin: idm_init() returns rc:0
03/16/22 10:52:26 plugin_pblock_new: Registered plugin
OCLC-IDM-Connector-Notifier 1.0 [OCLC.org] (Notify the OCLC IDM-Connector of
changes)
As I said, with OpenLDAP 2.4.40 this works fine. It does not work anymore with
2.6.1.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6461
--- Comment #10 from Howard Chu <hyc(a)openldap.org> ---
Escaping with a backslash appears to be non-portable. All the major SQL
implementations escape a single quote by doubling it, as done in the patch for
ITS#9815.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6461
Ryan Tandy <ryan(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=9815
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9816
Issue ID: 9816
Summary: slapcat cordeumps during mdb subtree dump with -s
Product: OpenLDAP
Version: 2.5.11
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: khoffmann(a)united-internet.de
Target Milestone: ---
Created attachment 887
--> https://bugs.openldap.org/attachment.cgi?id=887&action=edit
gdb backtrace of slapcat run
When trying to use slapcat in combination with -b and -s in order to create a
LDIF backup of a mdb subtree, slapd crashes with a coredump (please see the
attached snippet with gdb output from a reproduced test tree). The problem was
reporducible with different mdb databases / suffixes and only appears with
option -s.
The same dump with -H 'ldap:///ou=users,o=company,c=de??sub?' instead of -s
ou=users,o=company,c=de works perfectly fine, as long as the "attrs part" is
empty in the ldap-uri. Also using slapcat with -b only (for a full database
dump) works fine as well.
I'm aware of the fact that -s option is marked as DEPRECATED - I'm not sure if
you are going to fix this bug or if you rather take the change to remove the
option completely from future major versions.
Please let me also know if it's expected behaviour that the -H option doesn't
work whenever the attribute part isn't empty and if I should contribute to a
documentation update for this edge case.
Best regards,
Kris
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7978
ismael(a)iodev.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ismael(a)iodev.co.uk
--- Comment #13 from ismael(a)iodev.co.uk ---
Created attachment 889
--> https://bugs.openldap.org/attachment.cgi?id=889&action=edit
Fix building against LibreSSL
OpenLDAP 2.6.1 works fine against LibreSSL 3.4+.
The only problem is the configure script checks for a symbol LibreSSL doesn't
implement yet.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7089
OndÅ™ej KuznÃk <ondra(a)mistotebe.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=9813
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9810
Issue ID: 9810
Summary: slapacl peername
Product: OpenLDAP
Version: 2.4.59
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ratness(a)gmail.com
Target Milestone: ---
Found in 2.4.59 on a $WORK system, replicated in 2.6.1:
[root@centos-s-1vcpu-1gb-ams3-01 ~]# rpm -qf /opt/symas/sbin/slapacl
symas-openldap-servers-2.6.1-2.el7.x86_64
This is a box where I don't even have slapd running, but that's okay because my
point is visible without it:
[root@centos-s-1vcpu-1gb-ams3-01 ~]# /opt/symas/sbin/slapacl -F
/etc/openldap/slapd.d -D 'someuser' -b 'somewhere' -o peername.ip=127.0.0.1
entry/read
usage: slapacl [-v] [-d debuglevel] [-f configfile] [-F configdir] [-o
<name>[=<value>]]
[-U authcID | -D authcDN] [-X authzID | -o authzDN=<DN>]
-b DN [-u] [attr[/access][:value]] [...]
When I ask for `-o peername.ip=127.0.0.1` the `slapacl` command bails out with
usage, indicating a parse failure.
If I then run `slapacl` with `-o peername=ip=127.0.0.1`, I get:
[root@centos-s-1vcpu-1gb-ams3-01 ~]# /opt/symas/sbin/slapacl -F
/etc/openldap/slapd.d -D 'someuser' -b 'somewhere' -o peername=ip=127.0.0.1
entry/read
invalid config directory /etc/openldap/slapd.d, error 2
slapacl: bad configuration directory!
(which I would expect here since I have no server running)
Demo on 2.4.59 at work:
$ /usr/sbin/slapacl -F /etc/openldap/slapd.d -D
uid=replicator,ou=logins,dc=example -b 'mail=me(a)example.com,o=com,dc=mozilla'
-o peername=ip=127.0.0.1 entry/read
authcDN: "uid=replicator,ou=logins,dc=example"
read access to entry: ALLOWED
$ /usr/sbin/slapacl -F /etc/openldap/slapd.d -D
uid=replicator,ou=logins,dc=example -b 'mail=me(a)example.com,o=com,dc=mozilla'
-o peername=ip=127.0.0.2 entry/read
authcDN: "uid=replicator,ou=logins,dc=example"
read access to entry: DENIED
slapacl(8) mentions peername, but also aims us at slapd.access(5), which lists
peername[.<peernamesytle>].
It's possible I'm dense and this isn't a bug, but minimally the equalsign
repetition is really awkward to my eye. I'd suggest at least an example in
slapacl(8) so it's easier to figure out.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9807
Issue ID: 9807
Summary: Cannot enable {ARGON2} passwd scheme support
Product: OpenLDAP
Version: unspecified
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: gregory.widmer(a)gwidmer.fr
Target Milestone: ---
Created attachment 881
--> https://bugs.openldap.org/attachment.cgi?id=881&action=edit
Trace of every executed command.
I want to build OpenLDAP with argon2 support. Unfortunately, it doesn't work
and I don't understand why. It seems to be a build issue.
Here is how to reproduce the issue :
I'm using a fresh install of Debian 11.
The following packages were installed for this :
- libargon2-dev
- libltdl-dev
- git
- build-essential
I am using the master branch of the git repository :
https://git.openldap.org/openldap/openldap/-/commit/e8813b12b6188d5ba5f174f…
I'm using root, and the repo is under /root/openldap.
My objective is to :
- Run slapd with {ARGON2} support
- Set {ARGON2} as password-hash
- Use slappasswd to create a password for LDAP admin in slapd.conf
I ran the following commands :
- apt install libltdl-dev libargon2-dev git build-essential -y
- ./configure --with-argon2=libargon2 --enable-modules --enable-argon2=yes
- make depend
- make
- make check
- make install
I then created a systemd service for slapd, reloaded daemons with systemctl
then started the service.
I got the following error :
@(#) $OpenLDAP: slapd 2.X (Mar 12 2022 15:31:06) $
root@ldap:/root/openldap/servers/slapd
/usr/local/etc/openldap/slapd.conf: line 65: <password-hash> scheme not
available ({ARGON2})
/usr/local/etc/openldap/slapd.conf: line 65: <password-hash> no valid hashes
found
slapd stopped.
connections_destroy: nothing to destroy.
I don't understand how to build openldap with argon2. I did not find anything.
You will find a global trace file for every command used with the program.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9805
Issue ID: 9805
Summary: member attributes managed by autogroup are lost when
user attributes are adjusted
Product: OpenLDAP
Version: 2.4.59
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: michael.bobzin(a)baloise.ch
Target Milestone: ---
Hello OpenLDAP Team,
we use nested groups in our OpenLDAP directory.
User X is a member of group A.
Group A is a member of group B.
User X is therefore also a member of group B.
To be able to find out all groups of user X with only one LDAP query
we use the dynlist overlay together with the autogroup overlay.
Group B is a dynamic group whose member attributes are set with autogroup,
to allow a search for members.
ldapsearch .. -s sub -b "ou=groups,dc=basler,dc=ch"
"(member=cn=userx,ou=users,dc=basler,dc=ch)" dn
Result:
cn=groupA,ou=groups,dc=basler,dc=ch
cn=groupB,ou=groups,dc=basler,dc=ch
----- Gruppe A ----------------------------------------------------------
dn: cn=groupA,ou=groups,dc=basler,dc=ch
cn: groupA
objectClass: top
objectClass: groupOfNames
member:cn=userX,ou=users,dc=basler,dc=ch
----- Gruppe B ----------------------------------------------------------
dn: cn=groupB,ou=groups,dc=basler,dc=ch
cn: groupB
objectClass: top
objectClass: groupOfURLs
memberURL: ldap:///ou=groups,dc=basler,dc=ch?member?one?(cn=groupA)
# managed by autogroup
member:cn=userX,ou=users,dc=basler,dc=ch
-----------------------------------------------------------------------
This works until any attribute in the userX object is changed.
The member attribute for userX created dynamically by autogroup is then deleted
from groupB although userX is still a member of groupA and is therefore matched
with the search in the memberURL attribute of groupB matched.
The expected behaviour would be that the member attribute in groupB remains
unchanged.
----------- configuration --------------------------
OpenLDAP 2.4.59 from https://www.ltb-project.org/download.html
--------------- slapd.conf -------------------------
...
moduleload dynlist
moduleload autogroup.so
...
include /usr/local/openldap/etc/openldap/local-schema/dyngroup.schema
...
overlay dynlist
dynlist-attrset groupOfURLs memberURL
overlay autogroup
autogroup-attrset groupOfURLs memberURL member
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9497
Issue ID: 9497
Summary: back-ldif: test022-ppolicy failure
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: hamano(a)osstech.co.jp
Target Milestone: ---
The test022-ppolicy with back-ldif fail for two issue.
1. too short pwdMaxAge
~~~
$ ./run -b ldif test022-ppolicy
(snip)
Testing password expiration
Waiting seconds for password to expire...
sleep: missing operand
Try 'sleep --help' for more information.
Password expiration test failed
~~~
The script tries test for lockout and then a test for password expiration.
It will fail if the password has expired(pwdMaxAge: 30) by the time it starts
the password expiration test.
This is a timing issue and not directly caused by back-ldif.
However, the issue is reproduced only with back-ldif in my environment.
This test passed in my environment by extending pwdMaxAge by 5 seconds, but
there may be a better way.
2. duplicate ldap control response
~~~
Reconfiguring policy to remove grace logins...
Clearing forced reset...
expr: syntax error: unexpected argument '15'
Testing password expiration
Waiting seconds for password to expire...
sleep: missing operand
Try 'sleep --help' for more information.
~~~
This is back-ldif issue.
back-ldif responds duplicate ldap control response.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=5840
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.
https://bugs.openldap.org/show_bug.cgi?id=5840
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #12 from Howard Chu <hyc(a)openldap.org> ---
(In reply to OndÅ™ej KuznÃk from comment #11)
> Is this resolved with ITS#8958?
Yes
*** This issue has been marked as a duplicate of issue 8958 ***
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8958
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ralf(a)openldap.org
--- Comment #42 from Howard Chu <hyc(a)openldap.org> ---
*** Issue 5840 has been marked as a duplicate of this issue. ***
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=5840
--- Comment #11 from OndÅ™ej KuznÃk <ondra(a)mistotebe.net> ---
Is this resolved with ITS#8958?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9798
Issue ID: 9798
Summary: Clearing pending ops on Bind
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Some context first.
The only universal way of reset an arbitrary (SASL) bind in progress, at least
in my reading of RFC4511 is to send an anonymous bind op, so that's what the
load balancer does when needed (the client goes away, etc.).
Incidentally, this is also what the balancer chooses to do when the pending
bind needs to be "abandoned" when the backend doesn't respond within a
configured timeout. That's skating the edge of what RFC4511 allows, probably
just past it.
The issue:
When slapd receives a bind and another operation X (lloadd sends the above
mentioned "reset" bind) before that first bind starts processing, X gets added
into conn->c_ops_pending and does c_n_pending_ops++. Bind then eventually
invokes connection_abandon which forgets to zero out c_n_pending_ops and the
connection remains unusable forever. On the surface that's trivial to fix and a
fix is coming.
On the other hand, operation X in the pending list is actually discarded too,
so that kind of defeats the idea of trying to "abandon" the original bind and
completely reset the connection state. Question is, do we want to retain the
last bind in the pending list or does the balancer have to destroy the
connection unconditionally when a bind times out?
--
You are receiving this mail because:
You are on the CC list for the issue.