https://bugs.openldap.org/show_bug.cgi?id=9256
Bug ID: 9256
Summary: The ACLs required for SASL binding are not fully
documented
Product: OpenLDAP
Version: 2.5
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 727
--> https://bugs.openldap.org/attachment.cgi?id=727&action=edit
Patch massaging the SASL binding requirement docs
While some ACL requirements for SASL binding are documented, some are not.
E.g, that olcAuthzRegexp requires =x on objectClass when direct DN mapping is
not documented. Other requirements can be reasoned out based on the existing
documentation, but this can be very difficult when unfamiliar with all the
moving parts and the places they are documented. E.g. knowing that
(objectClass=*) is the default filter, and that there's _always_ _some_ filter,
and connecting this with ACLs required to do search-based SASL mapping.
The attached patch brings all the SASL binding requirements together in one
place in the docs and makes everything explicit. The word "SASL" is included,
for those searching for that keyword.
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=9502
Issue ID: 9502
Summary: Implement TCP_USER_TIMEOUT in meta and asyncmeta
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
Implement TCP_USER_TIMEOUT as an option to libldap and as a configuration
option in back-meta and back-asyncmeta
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9189
Bug ID: 9189
Summary: Add GSSAPI channel-bindings support
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: iboukris(a)gmail.com
Target Milestone: ---
Recently MS has announce they plan to enforce channel-bindings for LDAP over
TLS (ADV190023).
To support it on client side, we need to pass "tls-endpoint" bindings (RFC
5929) to the SASL plugin, and make use of that in GSSAPI.
See also:
https://github.com/cyrusimap/cyrus-sasl/pull/601
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9350
Issue ID: 9350
Summary: Expand test suite for null base
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Currently we have no tests that use the empty suffix (null base).
This is an entirely valid configuration setup, and there are unique challenges
and bugs that crop up with this usage.
We need to ensure we're covering this use case, particularly with syncrepl and
delta-syncrepl configurations.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9538
Issue ID: 9538
Summary: Accesslog entryCSN ordering is not always monotonous
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
For delta-sync replication, we rely on CSN order being preserved at all times.
When logops includes anything more than "writes", we don't use li_op_rmutex to
maintain serialisation. A concurrent write and another operation (like bind)
can have the write have its csn assigned before the bind. But before the write
finishes on the main DB and is logged, the bind has already hit accesslog.
This entry out of order doesn't match the usual filter, so non-persist sessions
will not notice, however running persist sessions could get a new cookie sent,
depending on how things are ordered when they hit syncprov.
A sample:
---- 8< ----
Apr 26 19:56:04 localhost slapd[43930]: conn=1003 op=41 ADD
dn="uid=dm01-R1H2-41660,ou=People,dc=example,dc=com"
Apr 26 19:56:04 localhost slapd[43930]: conn=1003 op=41 syncprov_matchops:
recording uuid for dn=reqStart=20210426195604.000350Z,cn=accesslog on
opc=0x7d3d2800dc50
Apr 26 19:56:04 localhost slapd[43930]: slap_get_csn: conn=1003 op=42 generated
new csn=20210426195604.556053Z#000000#002#000000 manage=1
Apr 26 19:56:04 localhost slapd[43930]: slap_queue_csn: queueing 0x7d3d38148f60
20210426195604.556053Z#000000#002#000000
Apr 26 19:56:04 localhost slapd[43930]: conn=1005 op=1 BIND
dn="dc=example,dc=com" method=128
Apr 26 19:56:04 localhost slapd[43930]: conn=1005 op=1 BIND
dn="dc=example,dc=com" mech=SIMPLE bind_ssf=0 ssf=256
Apr 26 19:56:04 localhost slapd[43930]: conn=1003 op=41 RESULT tag=105 err=0
qtime=0.005874 etime=0.015182 text=
Apr 26 19:56:04 localhost slapd[43930]: slap_get_csn: conn=1005 op=1 generated
new csn=20210426195604.558683Z#000000#002#000000 manage=1
Apr 26 19:56:04 localhost slapd[43930]: slap_queue_csn: queueing 0x561f09113f80
20210426195604.558683Z#000000#002#000000
Apr 26 19:56:04 localhost slapd[43930]: conn=1005 op=1 syncprov_matchops:
recording uuid for dn=reqStart=20210426195604.000364Z,cn=accesslog on
opc=0x561f0900fcf0
Apr 26 19:56:04 localhost slapd[43930]: conn=1002 op=2 syncprov_qresp: set up a
new syncres mode=4 csn=20210426195604.558683Z#000000#002#000000
Apr 26 19:56:04 localhost slapd[43930]: conn=1001 op=2 syncprov_qresp: set up a
new syncres mode=4 csn=20210426195604.558683Z#000000#002#000000
Apr 26 19:56:04 localhost slapd[43930]: conn=1000 op=2 syncprov_qresp: set up a
new syncres mode=4 csn=20210426195604.558683Z#000000#002#000000
Apr 26 19:56:04 localhost slapd[43930]: slap_graduate_commit_csn: removing
0x561f09113f80 20210426195604.558683Z#000000#002#000000
Apr 26 19:56:04 localhost slapd[43930]: conn=1005 op=1 RESULT tag=97 err=0
qtime=0.000020 etime=0.004297 text=
Apr 26 19:56:04 localhost slapd[43930]: slap_queue_csn: queueing 0x7d3d38148250
20210426195604.556053Z#000000#002#000000
Apr 26 19:56:04 localhost slapd[43930]: slap_graduate_commit_csn: removing
0x7d3d38148250 20210426195604.556053Z#000000#002#000000
Apr 26 19:56:04 localhost slapd[43930]: slap_graduate_commit_csn: removing
0x7d3d38148f60 20210426195604.556053Z#000000#002#000000
---- 8< ----
Example entries in the order slapcat sees them:
---- 8< ----
dn: reqStart=20210426195604.000364Z,cn=accesslog
objectClass: auditBind
reqStart: 20210426195604.000364Z
reqEnd: 20210426195604.000365Z
reqType: bind
entryCSN: 20210426195604.558683Z#000000#002#000000
dn: reqStart=20210426195604.000351Z,cn=accesslog
objectClass: auditAdd
reqStart: 20210426195604.000351Z
reqEnd: 20210426195604.000366Z
reqType: add
entryCSN: 20210426195604.556053Z#000000#002#000000
---- 8< ----
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9556
Issue ID: 9556
Summary: slapd-config should return invalidAttributeSyntax if
parsing schema description fails
Product: OpenLDAP
Version: 2.5.4
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: michael(a)stroeder.com
Target Milestone: ---
I'm currently testing error handling and interacting with LDAP clients (e.g. my
web2ldap).
Sending an invalid attribute type description results in an error (as expected)
returned by slapd-config:
RESULT tag=103 err=80 qtime=0.000032 etime=0.001271 text=olcAttributeTypes:
Unexpected token before SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
But result code other(80) seems not very useful. It's too unspecific to decide
on specific error handling.
It would be much more useful if slapd-config returns invalidAttributeSyntax(21)
in this case.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9576
Issue ID: 9576
Summary: Add ConfigTable link into ConfigArgs
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: enhancement
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Would make it possible to examine defaults if necessary.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9493
Issue ID: 9493
Summary: slapo-accesslog handling of deletion of multi-valued
configuration attributes removes wrong value from list
Product: OpenLDAP
Version: 2.4.57
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: svella(a)technologist.com
Target Milestone: ---
I observed this in the debugger while working on a small feature addition to
slapo-accesslog.
log_cf_gen(), when handling the initial configuration of oldAccessLogOldAttr
(accesslog.c:989), linked list li_oldattrs is being built by inserting each
value in order at the head of the list, resulting in the list being in reverse
order. But when handling LDAP_MOD_DELETE of same attribute (accesslog.c:989),
it is using the index of the removed value (valx) to find and removed the entry
in the linked list, but it's counting from the head of li_oldattrs and not the
tail, resulting in the wrong item being removed from the list unless counting
from the head or the tail happens find the same item.
(Line numbers refer to commit 6c469f07935e351e349bf38fc223dab704c51a76)
Handling of oldAccessLogBase appears to have the same problem, and a cursory
glance through the source of other overlays reveals a similar pattern, and I'm
guessing the same problem.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9282
Issue ID: 9282
Summary: Syncrepl re-creates deleted entry
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Scenario:
2 node Multi-provider replication
Add database to provider A
ensure database replicates to provider B
Stop provider A
delete entry on provider B
Start provider A
Wait for provider B to reconnect to provider A
Deleted entry re-appears
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9492
Issue ID: 9492
Summary: Add local logging capa
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: mhardin(a)symas.com
Target Milestone: ---
Enhancement request: Add capability to slapd to log to a local file with log
rotation features. Log format should not change from syslog-generated log
style.
--
You are receiving this mail because:
You are on the CC list for the issue.