[Bug 9246] New: Improve authzFrom/authzTo docs
by openldap-its@openldap.org
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.
1 year, 4 months
[Bug 9238] New: access control documentation is confusing
by openldap-its@openldap.org
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.
1 year, 4 months
[Issue 9283] New: Mutex leak in backend.c`backend_db_init()
by openldap-its@openldap.org
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.
1 year, 4 months
[Issue 9293] New: slapo-ppolicy stores pwdGraceUseTime only with seconds
by openldap-its@openldap.org
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.p...
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.
1 year, 4 months
[Issue 9400] New: Proxy bind retry fails after remote server disconnects
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9400
Issue ID: 9400
Summary: Proxy bind retry fails after remote server disconnects
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: tero.saarni(a)est.tech
Target Milestone: ---
Problem description
-------------------
I'm using slapd-ldap to proxy for a remote LDAP server. LDAP backend is
configured to:
- allow user binds that are passed directly to the remote LDAP server
- allow local user binds that are mapped to remote bind using idassert-bind
The problem happens when remote LDAP server abruptly disconnects the
(idle) LDAP connection. For example, next search operation will fail with
error:
Server is unavailable (52)
Additional information: misconfigured URI?
The operation will succeed when repeating it for second time.
Reproducing the problem
-----------------------
I created a test case that reproduces the problem
-
https://git.openldap.org/tsaarni/openldap/-/compare/master...ldap-back-re...
Preliminary troubleshooting
---------------------------
While troubleshooting this I observed following:
(A) The problem is related to retry after remote server abruptly dropped the
LDAP connection.
Call chain ldap_back_retry() -> ldap_back_dobind_int() ->
ldap_back_is_proxy_authz()
ends up in this branch:
if ( !( li->li_idassert_flags & LDAP_BACK_AUTH_OVERRIDE )) {
if ( op->o_tag == LDAP_REQ_BIND ) {
if ( !BER_BVISEMPTY( &ndn )) {
dobind = 0;
goto done;
}
where "dobind = 0" causes "binddn" and "bindcred" return variables NOT to be
filled.
Then in ldap_back_dobind_int() we fall into this branch:
if ( LDAP_BACK_CONN_ISIDASSERT( lc ) ) {
if ( BER_BVISEMPTY( &binddn ) && BER_BVISEMPTY( &bindcred ) ) {
/* if we got here, it shouldn't return result */
rc = ldap_back_is_proxy_authz( op, rs,
LDAP_BACK_DONTSEND, &binddn, &bindcred );
if ( rc != 1 ) {
Debug( LDAP_DEBUG_ANY, "Error: ldap_back_is_proxy_authz "
"returned %d, misconfigured URI?\n", rc );
rs->sr_err = LDAP_OTHER;
rs->sr_text = "misconfigured URI?";
LDAP_BACK_CONN_ISBOUND_CLEAR( lc );
if ( sendok & LDAP_BACK_SENDERR ) {
send_ldap_result( op, rs );
}
goto done;
}
}
(B) The problem does NOT occur if configuring separate instances of back-ldap:
- one backend for users: BIND is done with users own credentials - no idassert
- second backend for local admin: local admin BIND is overwritten with
idassert-bind
Possibly the same problem have been discussed also earlier, for example
- https://www.openldap.org/lists/openldap-technical/201307/msg00070.html
- https://www.openldap.com/lists/openldap-bugs/201511/msg00041.html
- https://www.openldap.org/lists/openldap-bugs/201905/msg00001.html
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 4 months
[Issue 9332] New: Compilation of 2.4.52 fails: "init.c", line 45: too many initializers for scalar
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9332
Issue ID: 9332
Summary: Compilation of 2.4.52 fails: "init.c", line 45: too
many initializers for scalar
Product: OpenLDAP
Version: 2.4.52
Hardware: All
OS: Solaris
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: stacey.marshall(a)gmail.com
Target Milestone: ---
The addition of integer ldo_tls_require_san to structure requires an additional
initialization digit to macro LDAP_LDO_TLS_NULLARG.
--- openldap-2.4.52/libraries/libldap/ldap-int.h 2020-08-28
09:10:00.000000000 -0700
+++ openldap-2.4.52.x/libraries/libldap/ldap-int.h 2020-09-01
10:08:44.661226154 -0700
@@ -263,7 +263,7 @@
int ldo_tls_impl;
int ldo_tls_crlcheck;
int ldo_tls_require_san;
-#define LDAP_LDO_TLS_NULLARG ,0,0,0,{0,0,0,0,0,0,0,0,0},0,0,0,0
+#define LDAP_LDO_TLS_NULLARG ,0,0,0,{0,0,0,0,0,0,0,0,0},0,0,0,0,0
#else
#define LDAP_LDO_TLS_NULLARG
#endif
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 4 months
[Issue 9426] New: Paged results return duplicates
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9426
Issue ID: 9426
Summary: Paged results return duplicates
Product: OpenLDAP
Version: 2.4.56
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
When performing a query that matches 744 entries, the number of returned
entries varies depending on the page size requested.
For a page size of 300, it returns 767 entries
For a page size of 500, it returns 759 entries
Running the results for sort -u correctly shows 744 unique entries. So
anywhere from 15 to 23 duplicates are returned in the above case.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 4 months