https://bugs.openldap.org/show_bug.cgi?id=9915
Issue ID: 9915
Summary: Changing slapo-unique to use serialize causes
cn=config replication to fail
Product: OpenLDAP
Version: 2.6.3
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: ---
I updated my slapo-unique configuration from:
olcUniqueURI: ldap:///?uid?sub?
to
olcUniqueURI: "serialize ldap:///?uid?sub?"
and replication of the config database fails with the following error:
syncrepl_null_callback: error code 0x50
syncrepl_entry: rid=001 be_modify
olcOverlay={2}unique,olcDatabase={2}mdb,cn=config (80)
syncrepl_entry: rid=001 be_modify failed (80)
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9897
Issue ID: 9897
Summary: ldapcompare return FALSE when dynlist in use
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: sdalu(a)sdalu.com
Target Milestone: ---
The server configuration enable dynlist with:
overlay dynlist
dynlist-attrset groupOfURLs memberURL member
Entry is:
dn: cn=Admins,ou=Services,ou=Members,dc=zog,dc=com
member: uid=foo,ou=People,dc=zog,dc=com
cn: Admins
objectClass: groupOfNames
The ldap compare will return false, was expected true
ldapcompare -x cn=Admins,ou=Services,ou=Members,dc=zog,dc=com
member:uid=foo,ou=People,dc=zog,dc=com
Now if I comment the dynlist-attrset directive, I will get TRUE for the same
ldapcompare request
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9925
Issue ID: 9925
Summary: Fix some compilation issues around usage of #if and
#ifdef
Product: OpenLDAP
Version: unspecified
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: connor.smith(a)hitachivantara.com
Target Milestone: ---
Created attachment 918
--> https://bugs.openldap.org/attachment.cgi?id=918&action=edit
git format-patch
I noticed a few issues while working with OpenLDAP that would lead to compiler
warnings and the like in our particular build environment. They're quite minor,
but it would still be good to have them patched upstream.
In include/ac/socket.h:
Use #elif defined(...) for HAVE_WINSOCK and MACOS. All other instances
of these macros use #ifdef or similar. A compiler may warn about them
not being defined.
In libraries/liblber/sockbuf.c, (DOS && PCNFS) and (DOS && NCSA) were
replaced with HAVE_PCNFS and HAVE_NCSA, respectively. It seems logical
to do the same at the only remaining occurrence of DOS, PCNFS, and NCSA.
For context on the latter: the actual warning was about #elif DOS, similar to
#elif HAVE_WINSOCK and #elif MACOS, but looking into it it seemed to make sense
to bring socket.h in line with sockbuf.c.
In libraries/liblunicode/ucdata/ucgendat.c:
Use #if HARDCODE_DATA consistently, replacing two instances of #ifdef.
HARDCODE_DATA is always defined, and this way you can set HARDCODE_DATA
to 0 and have it work, rather than it going down the wrong branch and
failing in these two cases.
An IPR notice, with this work having been done as part of my employment:
The attached file is derived from OpenLDAP Software. All of the
modifications to OpenLDAP Software represented in the following patch
were developed by Hitachi Vantara. Hitachi Vantara has not assigned
rights and/or interest in this work to any party. I, Connor Smith, am
authorized by Hitachi Vantara, my employer, to release this work under
the following terms.
Hitachi Vantara 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.
Please let me know if there are any issues with the attached patch, or if
there's anything else I need to do. Thanks.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9904
Issue ID: 9904
Summary: A Potential NPD
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: 1157401338(a)qq.com
Target Milestone: ---
Created attachment 911
--> https://bugs.openldap.org/attachment.cgi?id=911&action=edit
diagram of NPD
Hi, I found a NPD bug in the project source code of ldap, and I have shown the
execution sequence of the program that may have generated the bug on a
diagram,which is added to the attachment
The red text illustrates the steps that created the bug
the red arrows represent the call relationships
the file path can be seen in the blue framed section.
additionally,at step 4 I do not expand more detail about why function
ber_memalloc_x can return null(actually it can be seen as function malloc and
the reason ber_memalloc_x return null is same with malloc),because there are
many code snippet can be found in project source code that judge whether
ber_memalloc_x return null and make further process if return value equal to
null.
I look forward to your reply and thank you very much for your patience!
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9901
Issue ID: 9901
Summary: Fix non-standard printf arguments in liblbert and
libldap
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: michael.osipov(a)siemens.com
Target Milestone: ---
Created attachment 910
--> https://bugs.openldap.org/attachment.cgi?id=910&action=edit
Patch gainst source tarball
As a followup to Bug 9898 and Bug 9899 I have played around with LLVM 13 and
"-std=c17 -pedantic -Wall" it fails to compile several files. Find a patch
attached which makes it standards compliant.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9899
Issue ID: 9899
Summary: "cyrus.c" uses non-portable GNU extension for void
pointer arithmetics and fails on HP-UX aCC
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: Other
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: michael.osipov(a)siemens.com
Target Milestone: ---
On HP-UX with cc: HP C/aC++ B3910B A.06.29 [Oct 18 2016]
tells me
libtool: compile: /opt/aCC/bin/aCC -Ae -g -I../../include -I../../include
-I/opt/ports/include -DLDAP_LIBRARY -c cyrus.c -DPIC -o .libs/cyrus.o
"cyrus.c", line 420: error #3143: arithmetic on pointer to void or function
type
memcpy( cb_data + plen, cbv.bv_val, cbv.bv_len );
^
1 error detected in the compilation of "cyrus.c".
gmake[2]: *** [Makefile:434: cyrus.lo] Error 1
void pointer arithmetics is not valid/undefined and just a GNU extension
supported by GCC or clang.
I was able to reproduce this on FreeBSD clang version 13.0.0
(git@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a303):
osipovmi@deblndw011x:~/var/Projekte/openldap-2.6.3/libraries/libldap
$ cc -std=c17 -I../../include -I../../include -I/usr/local/include
-DLDAP_LIBRARY -c cyrus.c -o cyrus.o -pedantic -Werror
cyrus.c:420:18: error: arithmetic on a pointer to void is a GNU extension
[-Werror,-Wpointer-arith]
memcpy( cb_data + plen, cbv.bv_val, cbv.bv_len );
~~~~~~~ ^
1 error generated.
I am not a daily C hacker, but I guess cb_data needs to be typed to "unsigned
char" just like data from sasl_channel_binding_t
(https://github.com/cyrusimap/cyrus-sasl/blob/cb549ef71c5bb646fe583697ebdcab…).
Or at least a malloc with an "unsigned char", save the pointer start address,
copy the prefix, increment by prefix length, copy the channel binding value and
then assign the pointer start address to the output struct.
I will unset SASL_CHANNEL_BINDING for now since it is not required in your AD
environment when SASL GSSAPI with minssf=1 is set.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9941
Issue ID: 9941
Summary: back-asyncmeta(5) man page has incorrect information
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
Currently the man page states that asyncmeta selects the connection queue with
the least number of pending operations as the next connection, but that was
dropped a while ago, and the connections queues are selected round-robin.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9917
Issue ID: 9917
Summary: Remove -h and -p from options[] in client tools
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: daniels.thomas(a)pm.me
Target Milestone: ---
Created attachment 914
--> https://bugs.openldap.org/attachment.cgi?id=914&action=edit
patch for this issue
The options -h and -p got removed from client tools
(https://bugs.openldap.org/show_bug.cgi?id=8618). However, they were still
present in the options[] array in several client tools source files. So, if one
of those tools got executed with -h or -p followed by a value, this lead to the
error "unrecognized option -", without mentioning which option was problematic.
Removing 'h' and 'p' from options[] fixes this. This patch does that.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9908
Issue ID: 9908
Summary: LDAP* leak in slapd-tester children when retrying a
bind
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Happens in lloadd's test002 where the balancer routinely returns BUSY in
response to a bind.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9860
Issue ID: 9860
Summary: ldapsearch memory leaks
Product: OpenLDAP
Version: 2.5.12
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: hamano(a)osstech.co.jp
Target Milestone: ---
When using page control, The control value leaks with each goto getNextPage;
loop due to `i` and `nctrl` step back.
```
1114 getNextPage:
...
1124 save_nctrls = nctrls;
1125 i = nctrls;
```
```
1284 if ( ldap_create_page_control_value( ld,
1285 pageSize, &pr_cookie, &c[i].ldctl_value
) )
```
```
1445 /* step back to the original number of controls, so that
1446 * those set while parsing args are preserved */
1447 nctrls = save_nctrls;
```
```
1612 goto getNextPage;
```
--
You are receiving this mail because:
You are on the CC list for the issue.