https://bugs.openldap.org/show_bug.cgi?id=10259
Issue ID: 10259
Summary: Wrong RID sends when using syncrepl provider
Product: OpenLDAP
Version: 2.6.8
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: florent.david(a)gmail.com
Target Milestone: ---
When using a custom syncrepl consumer bind to an OpenLDAP v2.6.8 provider and
it quickly appears than this provider sends to our consumer a cookie with a
Replica ID different from the original one.
In the logs below, we clearly see a refreshAndPersist synchronization
initialized whith a RID with value 606. After a while, on the same connection,
OpenLDAP syncrepl provider sends a new cookie with RID=612
66f2ea7d.3b1f8427 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_op_search: got a
persistent search with a
cookie=rid=606,csn=20240924154708.334351Z#000000#000#000000
66f2ea7d.3b1fafc0 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_findbase: searching
66f2ea7d.3b20ca28 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_op_search: registered
persistent search
66f2ea7d.3b20e5bf 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_op_search: no change,
skipping log replay
66f2ea7d.3b20ed6a 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_op_search: nothing
changed, finishing up initial search early
66f2ea7d.3b20f874 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_sendinfo:
refreshDelete cookie=
66f2ea7d.3b229483 0x7fa80a5fd6c0 conn=92750 op=1 syncprov_search_response:
detaching op
66f2ed56.12f82965 0x7fa816dfe6c0 conn=92750 op=1 syncprov_qresp: set up a new
syncres mode=4 csn=20240924164822.305028Z#000000#000#000000
66f2ed56.12fa5399 0x7fa7f58fc6c0 conn=92750 op=1 syncprov_sendinfo: sending a
new cookie=rid=612,csn=20240924164822.305028Z#000000#000#000000
66f2ed8d.053d71e3 0x7fa8165fd6c0 conn=92750 op=1 syncprov_qresp: set up a new
syncres mode=4 csn=20240924164917.069189Z#000000#000#000000
66f2ed8d.05405bb4 0x7fa7ed3fc6c0 conn=92750 op=1 syncprov_sendinfo: sending a
new cookie=rid=612,csn=20240924164917.069189Z#000000#000#000000
Is it a normal behaviour ? Should consumer checks the Replica ID sends by
OpenLDAP before storing it ?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10265
Issue ID: 10265
Summary: Make it possible to change olcBkLloadListen at runtime
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: lloadd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Currently, olcBkLloadListen changes only take effect on lloadd startup:
- an added olcBkLloadListen should come online at the end of the modify
operation
- at the end of the modify operation a removed olcBkLloadListen will stop
listening on the sockets associated with it, clients that connected over these
are marked CLOSING
- to facilitate replacing a value where URIs resolved sockets overlap,
olcBkLloadListen should become a MAY in olcBkLloadConfig objectclass
Lloadd's startup was modelled upon slapd's, but the requirements have changed
considerably when it was turned into a module. Sockets are acquired at module
configuration time, which is much later than standalone/slapd's own startup and
so the way the URLs are handled also needs to be reworked. This will resolve
other related issues.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10269
Issue ID: 10269
Summary: slap-constraint: Refactor to use a sorted array
Product: OpenLDAP
Version: 2.6.8
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
As noted in the comments for slapo-constraint:
/*
* Linked list of attribute constraints which we should enforce.
* This is probably a sub optimal structure - some form of sorted
* array would be better if the number of attributes constrained is
* likely to be much bigger than 4 or 5. We stick with a list for
* the moment.
*/
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9367
Issue ID: 9367
Summary: back-mdb: encryption support
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Need to add encryption support to the back-mdb backend, depends on issue#9364
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9204
Bug ID: 9204
Summary: slapo-constraint allows anyone to apply Relax control
Product: OpenLDAP
Version: 2.4.49
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ryan(a)openldap.org
Target Milestone: ---
slapo-constraint doesn't limit who can use the Relax control, beyond the global
limits applied by slapd. In practice, for many modifications this means any
configured constraints are advisory only.
In my opinion this should be considered a bug, in design if not implementation.
I expect many admins would not read the man page closely enough to realize the
behaviour does technically adhere to the letter of what's written there.
Either slapd should require manage privileges for the Relax control globally,
or slapo-constraint should perform a check for manage privilege itself, like
slapo-unique does.
Quoting ando in https://bugs.openldap.org/show_bug.cgi?id=5705#c4:
> Well, a user with "manage" privileges on related data could bypass
> constraints enforced by slapo-constraint(5) by using the "relax"
> control. The rationale is that a user with manage privileges could be
> able to repair an entry that needs to violate a constraint for good
> reasons. Note that the user:
>
> - must have enough privileges to do it (manage)
>
> - must inform the DSA that intends to violate the constraint (by using
> the control)
but such privileges are currently not being required.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=6198
OndÅ™ej KuznÃk <ondra(a)mistotebe.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ryan(a)openldap.org
--- Comment #7 from OndÅ™ej KuznÃk <ondra(a)mistotebe.net> ---
*** Issue 9211 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=6462
OndÅ™ej KuznÃk <ondra(a)mistotebe.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|1 |0
Target Milestone|--- |2.7.0
Resolution|SUSPENDED |---
Status|VERIFIED |UNCONFIRMED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=5919
OndÅ™ej KuznÃk <ondra(a)mistotebe.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|SUSPENDED |---
Target Milestone|--- |2.7.0
Status|VERIFIED |UNCONFIRMED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9042
OndÅ™ej KuznÃk <ondra(a)mistotebe.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|bugs(a)openldap.org |ondra(a)mistotebe.net
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10258
Issue ID: 10258
Summary: test050 failure: connection_close race?
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: ---
Created attachment 1032
--> https://bugs.openldap.org/attachment.cgi?id=1032&action=edit
tail of slapd log
Running test050 repeatedly, the slapd managed to get itself into an apparent
inconsistency in the connections structure. The logs suggest that there might
be a race closing the connection. Unfortunately the sanitiser didn't initiate a
core dump in this case.
--
You are receiving this mail because:
You are on the CC list for the issue.