https://bugs.openldap.org/show_bug.cgi?id=9292
Issue ID: 9292
Summary: Man page for LDAP_OPT_TIMEOUT/LDAP_OPT_NETWORK_TIMEOUT
unclear on use of free
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: sshanks(a)kx.com
Target Milestone: ---
Ref:
https://git.openldap.org/openldap/openldap/-/blob/master/doc/man/man3/ldap_…https://www.openldap.org/software/man.cgi?query=ldap_get_option&sektion=3&a…
See details of LDAP_OPT_TIMEOUT and LDAP_OPT_NETWORK_TIMEOUT.
Both state
"the caller has to free *outvalue"
This can be interpreted as the called must call free on outvalue.
This can cause a random crash when 'free' used (build on Linux ran ok, Windows
crashed immediately)
Would be better is it stated that the caller must use 'ldap_memfree', in the
same way as other options state use must use 'ldap_memfree'.
FYI: within the code, get_option for these params calls ldap_int_timeval_dup
which calls LDAP_MALLOC
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9238
Bug ID: 9238
Summary: access control documentation is confusing
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: kop(a)karlpinc.com
Target Milestone: ---
Created attachment 716
--> https://bugs.openldap.org/attachment.cgi?id=716&action=edit
git format-patch output
slapd.access says "Access control checking stops
at the first match of the <what> and <who> clause, unless
otherwise dictated by the <control> clause." But
this, by itself, is wrong. You have to read the next
sentence, which says there's an implicit "by * none
stop", meaning that the default is to stop when only <what>
matches.
Patch attached.
I, Karl O. Pinc, hereby place the following modifications to OpenLDAP Software
(and only these modifications) into the public domain. Hence, these
modifications may be freely used and/or redistributed for any purpose with or
without attribution and/or other notice.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9246
Bug ID: 9246
Summary: Improve authzFrom/authzTo docs
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: kop(a)karlpinc.com
Target Milestone: ---
Created attachment 724
--> https://bugs.openldap.org/attachment.cgi?id=724&action=edit
Patch
The defaults for group/objectclass/attributetype were not documented.
Improve the section overall.
I, Karl O. Pinc, hereby place the following modifications to OpenLDAP Software
(and only these modifications) into the public domain. Hence, these
modifications may be freely used and/or redistributed for any purpose with or
without attribution and/or other notice.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9283
Issue ID: 9283
Summary: Mutex leak in backend.c`backend_db_init()
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: ---
@backend_db_init:
if bi_db_init() fails, but [BackendDB *be] is not listed in [slap_be_head
backendDB] list of backends, then be->be_pcl_mutex is not destroyed.
| BackendDB *
| backend_db_init( ... )
| {
| ...
| ldap_pvt_thread_mutex_init( &be->be_pcl_mutex );
| ...
| if ( bi->bi_db_init )
| rc = bi->bi_db_init( be, cr );
|
| if ( rc != 0 ) {
| if ( !b0 ) {
| ...
| ldap_pvt_thread_mutex_destroy( &be->be_pcl_mutex );
| ch_free( be );
Additionally, it does not look like that owner of [b0] cares about destroying
this mutex.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9293
Issue ID: 9293
Summary: slapo-ppolicy stores pwdGraceUseTime only with seconds
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: michael(a)stroeder.com
Target Milestone: ---
If password is expired slapo-ppolicy can return the number of grace logins for
changing own password (graceAuthNsRemaining).
slapd derives graceAuthNsRemaining from number of pwdGraceUseTime values. But
those timestamps are only stored with a granularity of a second.
Thus multiple grace logins are possible within a second without decremeting
graceAuthNsRemaining value.
This is unexpected and also leads to absurd work-arounds when writing automated
tests like this:
https://gitlab.com/ae-dir/python-ldap0/-/blob/master/tests/test_ppolicy.py#…
Either a real Integer counter should be used or fraction of seconds should be
used in pwdGraceUseTime values.
This is a similar problem like pwdFailureTime solved in ITS#7161.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9322
Issue ID: 9322
Summary: Update admin guide to recommend OpenSSL 1.1 as a
minimum release
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: ---
For OpenLDAP 2.5, we need to update the recommended OpenSSL version to be 1.1
or later.
appendix-recommended-versions.sdf
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9205
Bug ID: 9205
Summary: Openldap 2.4.49 with overlays
syncrepl+ppolicy+chain+ldap
Product: OpenLDAP
Version: 2.4.49
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: ---
Created attachment 700
--> https://bugs.openldap.org/attachment.cgi?id=700&action=edit
test script copied from test022-ppolicy and modified to show the trouble
Hello,
I'm doing a OpenLDAP test with a master/slave replication configuration
including ppolicy overlay. I would like to enable password change from the
slave replica with chain overlay, in order to validate the ppolicy
olcPPolicyForwardUpdates attribute to TRUE. I'm using LDAPS from slave to
master with SASL External authentication with client certificate. The client
certificate correspond to a user DN entry with "manage" rights on the master
server (the same used for the replication). This user DN has authzTo attribute
in order to match the correct PROXYAUTHZ request from its dn to user DN.
All of this configuration works on replica when i do first a failed
authentication (err=49) on replica. The pwdFailureTime value is updated on the
DN entry from replica to slave normally. I'm also able to do after some self
entry update on some attribute such as password or others from replica to
master.
But the weird behavior is that i need to run first an failed authentication,
otherwise if i try to change attribute on the slave server, it respond an
err=80 "Error: ldap_back_is_proxy_authz returned 0, misconfigured URI?". The
only way to retrieve correct behavior is to restart slapd, and redo one failed
authentication first. It seems that the chain overlay do not connect the master
server at startup.
I've done a modification of test script test022-ppolicy to test022-policy-chain
which use the same LDIF source and show the problem of modification on the
consumer not "relayed" to the supplier if a fail operation is not done before.
Regards
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9222
Bug ID: 9222
Summary: Fix presence list to use a btree instead of an AVL
tree
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
[23:34] <hyc> ok, so far heap profile shows that memory use during refresh is
normal
[23:35] <hyc> not wonderful, but normal. mem usage grows because we're
recording the present list while receiving entries in the refresh
[23:36] <hyc> I'm seeing for 1.2GB of data about 235MB of presentlist
[23:36] <hyc> which is pretty awful, considering presentlist is just a list of
UUIDs
[23:36] <hyc> being stored in an avl tree
[23:37] <hyc> a btree would have been better here, and we could just use an
unsorted segmented array
[23:42] <hyc> for the accumulation phase anyway. we need to be able to lookup
records during the delete pphase
[00:05] <hyc> this stuff seriously needs a rewrite
[01:13] <hyc> 2.8M records x 16 bytes per uuid so this should be no more than
48MB of overhead
[01:13] <hyc> and instead it's 3-400MB
--
You are receiving this mail because:
You are on the CC list for the bug.