openldap-bugs September 2020

openldap-bugs@openldap.org

4 participants
300 discussions

[Bug 9204] New: slapo-constraint allows anyone to apply Relax control
by openldap-its＠openldap.org 08 Oct '24

08 Oct '24

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.

1 12

[Bug 9211] New: Relax control is not consistently access-restricted
by openldap-its＠openldap.org 08 Oct '24

08 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9211 Bug ID: 9211 Summary: Relax control is not consistently access-restricted Product: OpenLDAP Version: 2.4.49 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- The following operations can be performed by anyone having 'write' access (not even 'manage') using the Relax control: - modifying/replacing structural objectClass - adding/modifying OBSOLETE attributes Some operations are correctly restricted: - adding/modifying NO-USER-MODIFICATION attributes marked as manageable (Modification of non-conformant objects doesn't appear to be implemented at all.) In the absence of ACLs for controls, I'm of the opinion that all use of the Relax control should require manage access. The Relax draft clearly and repeatedly discusses its use cases in terms of directory _administrators_ temporarily relaxing constraints in order to accomplish a specific task. -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Issue 9303] New: Add support for WolfSSL as an alternative to OpenSSL
by openldap-its＠openldap.org 03 Oct '24

03 Oct '24

https://bugs.openldap.org/show_bug.cgi?id=9303 Issue ID: 9303 Summary: Add support for WolfSSL as an alternative to OpenSSL Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- For OpenLDAP 2.6, we should investigate adding support for WolfSSL as an alternative to OpenSSL. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 9343] New: Expand ppolicy policy configuration to allow URL filter
by openldap-its＠openldap.org 17 Sep '24

17 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=9343 Issue ID: 9343 Summary: Expand ppolicy policy configuration to allow URL filter Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Currently, ppolicy only supports a single global default policy, and past that any policies must be manually added to a given user entry if they are supposed to have something other than the default policy. Also, some sites want no default policy, and only a specific subset to have a policy applied to them. For both of these cases, it would be helpful if it were possible to configure a policy to apply to a set of users via a URL similar to the way we handle creating groups of users in dynlist -- You are receiving this mail because: You are on the CC list for the issue.

1 14

[Issue 9305] New: ldap_connect_to_host: Return code from getaddrinfo() discarded, troubleshooting difficult
by openldap-its＠openldap.org 10 Sep '24

10 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=9305 Issue ID: 9305 Summary: ldap_connect_to_host: Return code from getaddrinfo() discarded, troubleshooting difficult Product: OpenLDAP Version: 2.4.46 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: minfrin(a)sharp.fm Target Milestone: --- When the ldap_connect_to_host() function sees a failure from getaddrinfo(), the meaningless return code -1 is returned. This makes troubleshooting difficult on a webserver, where the low level printf debugging is not practical. (gdb) step ldap_connect_to_host (ld=ld@entry=0x7fffc4002e10, sb=0x7fffc400b240, proto=1, srv=srv@entry=0x7fffc400b2f0, async=async@entry=0) at os-ip.c:543 543 { (gdb) next 546 ber_socket_t s = AC_SOCKET_INVALID; (gdb) 562 if ( srv->lud_host == NULL || *srv->lud_host == 0 ) { (gdb) 568 port = srv->lud_port; (gdb) 570 if( !port ) { (gdb) 578 switch(proto) { (gdb) 580 osip_debug( ld, (gdb) warning: Source file is more recent than executable. 71 return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest)); (gdb) 598 hints.ai_flags = AI_ADDRCONFIG; (gdb) 601 hints.ai_socktype = socktype; (gdb) 602 snprintf(serv, sizeof serv, "%d", port ); (gdb) 605 LDAP_MUTEX_LOCK(&ldap_int_resolv_mutex); (gdb) 607 err = getaddrinfo( host, serv, &hints, &res ); (gdb) 609 LDAP_MUTEX_UNLOCK(&ldap_int_resolv_mutex); (gdb) 611 if ( err != 0 ) { (gdb) 612 osip_debug(ld, "ldap_connect_to_host: getaddrinfo failed: %s\n", (gdb) print host $3 = <optimized out> (gdb) print serv $4 = "636\000\000\000" (gdb) next 614 return -1; (gdb) The ldap_connect_to_host() function needs to return proper error codes. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Bug 9225] New: back-mdb: Add support for PREPARE/2-phase commit
by openldap-its＠openldap.org 10 Sep '24

10 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=9225 Bug ID: 9225 Summary: back-mdb: Add support for PREPARE/2-phase commit Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Add support for PREPARE/2-phase commit in back-mdb -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 9186] New: RFE: More metrics in cn=monitor
by openldap-its＠openldap.org 10 Sep '24

10 Sep '24

https://bugs.openldap.org/show_bug.cgi?id=9186 Bug ID: 9186 Summary: RFE: More metrics in cn=monitor Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- Currently I'm grepping metrics from syslog with mtail: https://gitlab.com/ae-dir/ansible-ae-dir-server/-/blob/master/templates/mta… With a new binary logging this is not possible anymore. Thus it would be nice if cn=monitor provides more metrics. 1. Overall connection count per listener starting at 0 when started. This would be a simple counter added to: entries cn=Listener 0,cn=Listeners,cn=Monitor 2. Counter for the various "deferring" messages separated by the reason for deferring. 3. Counters for all possible result codes. In my mtail program I also label it with the result type. -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 9193] New: HTML in mailing list description
by openldap-its＠openldap.org 19 Mar '24

19 Mar '24

https://bugs.openldap.org/show_bug.cgi?id=9193 Bug ID: 9193 Summary: HTML in mailing list description Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- e.g. https://lists.openldap.org/postorius/lists/openldap-devel.openldap.org/ contains code for links and formatting, but all inside of a <pre> block. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Issue 9341] New: Delta-sync MPR needs to be stable regardless of ordering
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9341 Issue ID: 9341 Summary: Delta-sync MPR needs to be stable regardless of ordering Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: replication Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If two or more updates are spread across several providers before they have a chance to learn about the others, all replicas need to arrive at the same content regardless of the order in which they arrive. One example that is broken at the moment: - (csn a) server 1 accepts a modify - (csn b) server 2 accepts a delete on the same DN - (csn c) server 2 accepts an add on that DN again If a replica receives the actions in the order bca vs. abc, the content of the entry will be different even though the final CSN set is the same -> they will never converge. The ordering 'bac' also needs to result in eventual convergence, even if it means a refresh or replication from either provider stalling temporarily? Merge request with this test case (so far): https://git.openldap.org/openldap/openldap/-/merge_requests/145 -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 9272] New: Invalid search results for subordinate/glued database
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9272 Issue ID: 9272 Summary: Invalid search results for subordinate/glued database Product: OpenLDAP Version: 2.4.47 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: grapvar(a)gmail.com Target Milestone: --- Here is a trivial test case. Look at the following bunch of glued dit's/databases, declared in this order: | suffix ou=a,ou=1,ou=T # subordinate; contains only one (top-level) entry | suffix ou=2,ou=T # subordinate; contains only one (top-level) entry | suffix ou=b,ou=1,ou=T # subordinate; contains only one (top-level) entry | suffix ou=T # master database, has two entries, top-level | ` ou=1 # ... and this child entry let's query the united database: | $ ldapsearch -b ou=1,ou=T -s sub '' nx | dn: ou=1,ou=T | dn: ou=a,ou=1,ou=T | dn: ou=b,ou=1,ou=T Nice! But wait, what if ... | $ ldapsearch -b ou=1,ou=T -s sub -E\!pr=2/noprompt '' nx | dn: ou=1,ou=T | dn: ou=a,ou=1,ou=T | | # pagedresults: cookie=//////////8= ... BANG! ... | Server is unwilling to perform (53) The problem is the glue_op_search(), which has issues * different parts of code make different assumptions about data structures * different parts of code track state inconsistently * code that looks like a highly probably dead code I mean that likely possible to build another bug-triggering test cases, and glue_op_search() needs not just a fix of the bug above, but intense cleaning and structuring. -- You are receiving this mail because: You are on the CC list for the issue.

1 13

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2020