June 2017 - openldap-bugs

(ITS#8681) dynlist overlay fails to generate attributes when paging is used

by jengelh＠inai.de

Full_Name: Jan Engelhardt Version: 2.4.44, 2.4.45 OS: Linux 4.11, openSUSE Tumbleweed 20170626 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (77.178.174.83) I observed that the dynlist overlay fails to generate its attributes for certain DNs. Ultimately it appears to relate to the chosen page size with which the database is queried; the smaller, the more often it occurs. Reproduce as follows: 1. Set up dynlist in slapd.conf for the database: include rfc2307bis.schema include dyngroup.schema database hdb suffix o=da index objectClass eq rootdn cn=root,o=da overlay dynlist dynlist-attrset posixAccount labeledURI memberOf 2. Construct some entries, such as: dn: cn=users,o=da member: uid=foo,o=da cn: users objectClass: groupOfNames objectClass: top objectClass: posixGroup gidNumber: 1555 description: users memberUid: foo dn: uid=foo,o=da objectClass: top objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount cn: foo displayName: Foo givenName: foo sn: foo uid: foo mail: foo(a)dagent.lh gidNumber: 1555 homeDirectory: /home/foo uidNumber: 25122 labeledURI: ldap:///o=da??sub?(&(objectClass=posixGroup)(memberUid=foo)) 3. Query database with a sufficiently small page size: ## ldapsearch -xb o=da -E pr=1 dn: o=da [ a little trimmed for brevity] control: 1.2.840.113556.1.4.319 false MA0CAQAECAEAAAAAAAAA pagedresults: cookie=AQAAAAAAAAA= dn: cn=root,o=da [] pagedresults: cookie=AgAAAAAAAAA= Press [size] Enter for the next {1|size} entries. dn: cn=users,o=da [] pagedresults: cookie=CAAAAAAAAAA= Press [size] Enter for the next {1|size} entries. dn: uid=foo,o=da objectClass: top objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount cn: foo displayName: Foo Beyond givenName: foo sn: foo uid: foo mail: foo(a)dagent.lh gidNumber: 1555 homeDirectory: /home/foo uidNumber: 25122 labeledURI: ldap:///o=da??sub?(&(objectClass=posixGroup)(memberUid=foo)) # search result search: 5 result: 0 Success control: 1.2.840.113556.1.4.319 false MAUCAQAEAA== pagedresults: cookie= With larger pagesizes or completely omitting -E pr, memberOf does appear: labeledURI: ldap:///o=da??sub?(&(objectClass=posixGroup)(memberUid=foo)) memberOf: cn=users,o=da

5 years, 9 months

1
0
0 / 0

Re: (ITS#8680) OpenLDAP 2.4.45 for Windows

by quanah＠symas.com

--On Friday, June 30, 2017 2:12 PM +0000 muthamma.appaiah(a)wellsfargo.com wrote: > Full_Name: Svetlana > Version: 2.4.45 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2620:160:e708:6::c) > > > Hi team, > > Could you please help us with the source file of 2.4.45 for Windows > operating system from your website? Hello, The ITS system is for reporting bugs with the OpenLDAP software. It is not the proper location for asking for help. If you need assistance with compiling OpenLDAP on Windows, the correct forum for asking for that help would be the openldap-technical(a)openldap.org list. Alternatively, I would note that my company (Symas) provides pre-built binaries of OpenLDAP for Windows with options for support. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

5 years, 9 months

1
0
0 / 0

(ITS#8680) OpenLDAP 2.4.45 for Windows

by muthamma.appaiah＠wellsfargo.com

Full_Name: Svetlana Version: 2.4.45 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2620:160:e708:6::c) Hi team, Could you please help us with the source file of 2.4.45 for Windows operating system from your website?

5 years, 9 months

1
0
0 / 0

(ITS#8679) Update release download page

by quanah＠openldap.org

Full_Name: Quanah Gibson-Mount Version: N/A OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) Download page needs updating to: a) Have links to the checksums for the release tarballs b) Have an encrypted download link option

5 years, 9 months

1
0
0 / 0

(ITS#8678) Slow deletes of large indexed attrributes

by hyc＠openldap.org

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.231.31) Submitted by: hyc Related to ITS#7329 Recalculating the index values can be quite expensive when deleting a value from an attribute with many values. For 2.5 we should fix this by storing reference counts with each index slot.

5 years, 9 months

1
0
0 / 0

Re: (ITS#8100) Empty accesslog causes issues with delta-syncrepl MMR configurations

by quanah＠symas.com

--On Thursday, April 09, 2015 5:42 AM +0000 quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.39 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (50.25.188.166) > > > When one has an MMR setup using delta-syncrepl, and the masters get into a > situation where one is out of sync, or adding a new MMR node to an > existing cluster, things will be broken until the new/reloaded node has a > write op that goes to the accesslog DB. In an existing cluster, where a > node is being reloaded, it causes all nodes to go into an endless looping > fallback sync until that write occurs. One possible fix for this, would be to refuse to delete the final entry in the accesslog during the purge phase. That way, the accesslog would never be empty. I'm not sure how difficult this would be to implement, code wise. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

5 years, 9 months

1
0
0 / 0

Re: (ITS#8677) back-sock segfaults on CONTINUE (database sock)

by michael＠stroeder.com

hyc(a)symas.com wrote: >> When using back-sock (database sock) and the external sock listener returns >> CONTINUE then slapd seg faults. >> >> Yes, returning CONTINUE is only allowed when using back-sock as overlay. >> But slapd should not seg fault and rather return as LDAP result: > > No. This is a configuration error and it's appropriate to halt the server and > force it to be fixed. Even if I follow your argument this message does not look like the server was deliberately halted: slapd: result.c:83: sock_read_and_send_results: Assertion `si->si_ops != 0' failed. ./start-slapd.sh: line 21: 30179 Aborted (core dumped) ${OPENLDAP_EXEC} -d stats,shell -h "ldap://0.0.0.0:9876 ${LDAPI_URI}" -n slapd-sock-test -f slapd.conf Also the args and PID files are not cleaned up. I guess database environment(s) of other backend(s) is/are also not closed in a controlled manner. So at least it should properly log a message and shutdown cleanly. Ciao, Michael.

5 years, 9 months

1
0
0 / 0

Re: (ITS#8677) back-sock segfaults on CONTINUE (database sock)

by hyc＠symas.com

michael(a)stroeder.com wrote: > Full_Name: > Version: 2.4.45 > OS: Linux > URL: > Submission from: (NULL) (213.240.182.98) > > > When using back-sock (database sock) and the external sock listener returns > CONTINUE then slapd seg faults. > > Yes, returning CONTINUE is only allowed when using back-sock as overlay. > But slapd should not seg fault and rather return as LDAP result: > > result: 80 Other (e.g., implementation specific) error > text: CONTINUE not allowed for back-sock No. This is a configuration error and it's appropriate to halt the server and force it to be fixed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

5 years, 9 months

1
0
0 / 0

(ITS#8677) back-sock segfaults on CONTINUE (database sock)

by michael＠stroeder.com

Full_Name: Version: 2.4.45 OS: Linux URL: Submission from: (NULL) (213.240.182.98) When using back-sock (database sock) and the external sock listener returns CONTINUE then slapd seg faults. Yes, returning CONTINUE is only allowed when using back-sock as overlay. But slapd should not seg fault and rather return as LDAP result: result: 80 Other (e.g., implementation specific) error text: CONTINUE not allowed for back-sock

5 years, 9 months

1
0
0 / 0

Re: (ITS#8676) openldap source uses implicit functoin declarations

by h.b.furuseth＠usit.uio.no

On 19. juni 2017 23:19, slyfox(a)gentoo.org wrote: > Why those are problems? implicit function declarations mean the > function type will be defaulted to int(int, int). > For functions like > int slap_sasl_cbinding( Connection *conn, struct berval *cbv ); > it might cause pointer-to-int truncation on 64-bit platforms. No, implicit declarations are defaulted to int(), and function call args are not converted other than integer promotions. So it's not a problem when the function are called with args of the correct types. But yeah, it won't hurt to clean up. -- Hallvard

5 years, 9 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2017