openldap-bugs May 2013

openldap-bugs@openldap.org

30 participants
83 discussions

(ITS#7583) ldap_init_fd() does not work with LDAP_PROTO_UDP
by stefw＠redhat.com 03 May '13

03 May '13

Full_Name: Stef Walter Version: 2.4.35 OS: Fedora 18 URL: http://fedorapeople.org/~stefw/patches/openldap-02/0001-Make-ldap_init_fd-w… Submission from: (NULL) (77.3.95.123) The ldap_init_fd() function does not work with UDP sockets (ie: LDAP_PROTO_UDP passed in as the proto argument). Later uses of the LDAP connection returned fail unceremoniously. This patch fixes the issue: http://fedorapeople.org/~stefw/patches/openldap-02/0001-Make-ldap_init_fd-w… Some test code to exercise and demonstrate the problem. The code does not actually wait for a UDP response, but should exit with a zero return code when successful. http://fedorapeople.org/~stefw/patches/openldap-02/frob-cldap-initfd.c $ gcc -o frob-cldap-initfd -Wall -lldap -llber frob-cldap-initfd.c $ ./frob-cldap-initfd frob-cldap-initfd: ldap_search_ext: -1 The above result occurs before the patch is applied.

1 0

(ITS#7582) Access to uninitialized memory when sending cldap packet
by stefw＠redhat.com 02 May '13

02 May '13

Full_Name: Stef Walter Version: 2.4.35 OS: Fedora 18 URL: http://fedorapeople.org/~stefw/patches/openldap-01/0001-Fix-usage-of-uninit… Submission from: (NULL) (77.3.95.123) When sending a cldap (UDP) packet, like a search request, uninitialized memory is accessed. This shows up in valgrind like this: ==31445== Conditional jump or move depends on uninitialised value(s) ==31445== at 0x36632244E6: ldap_send_server_request (request.c:377) ==31445== by 0x36632247C2: ldap_send_initial_request (request.c:166) ==31445== by 0x36632142F8: ldap_pvt_search (search.c:128) ==31445== by 0x366321454F: ldap_search_ext (search.c:69) ==31445== by 0x400838: main (in /data/projects/openldap/frob-cldap-search) ==31445== This is due to parsing the resulting packet to pull out a requestDN. UDP packets have different BER layout, and therefore the assumptions made when parsing the outgoing request are invalid. It does not seem necessary to track the request DN for UDP packets. The linked patch disables this code path for UDP packets. Patch which fixes the issue: http://fedorapeople.org/~stefw/patches/openldap-01/0001-Fix-usage-of-uninit… Test code for the issue: http://fedorapeople.org/~stefw/patches/openldap-01/frob-cldap-search.c Note that the test code doesn't detect the issue on its own (or do anything useful). Use valgrind to detect the issue: $ gcc -o frob-cldap-search -Wall -lldap -llber frob-cldap-search.c $ valgrind ./frob-cldap-search

1 0

(ITS#7581) adding meta backend in cn=config with ldapadd / ldapmodify
by dcoutadeur＠linagora.com 02 May '13

02 May '13

Full_Name: dcoutadeur Version: 2.4.35 / git OS: openSuse 11.3 x86_64 URL: Submission from: (NULL) (80.67.162.201) I apologize in advance if this is not considered as a bug, but I thought this ticket should help the community anyway... The problem is that it seems impossible to add meta backend in cn=config thanks to ldapadd / ldapmodify clients. I thought the major interest for cn=config was precisely to let administrators change the configuration in a remote way, but maybe new database configuration is an exception ? Here are the technical elements : Content of meta.ldif : dn: olcDatabase={2}meta,cn=config objectClass: olcDatabaseConfig objectClass: olcMetaConfig olcDatabase: {2}meta olcSuffix: dc=foo,dc=com debug information in slapd, after the command : ldapadd -H "ldap://localhost:389" -D "cn=config" -W -f meta.ldif 518220f1 conn=1002 op=1 ADD dn="olcDatabase={2}meta,cn=config" 518220f1 meta_back_db_open: no targets defined 518220f1 backend_startup_one (type=meta, suffix="dc=foo,dc=com"): bi_db_open failed! (1) 518220f1 olcSuffix: value #0: <olcSuffix> failed startup (dc=foo,dc=com)! However, I can add this entry via slapadd : dn: olcDatabase={2}meta,cn=config objectClass: olcDatabaseConfig objectClass: olcMetaConfig olcDatabase: {2}meta olcSuffix: dc=foo,dc=com olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcSyncUseSubentry: FALSE olcMonitoring: FALSE olcDbOnErr: continue olcDbPseudoRootBindDefer: TRUE olcDbSingleConn: FALSE olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbBindTimeout: 100000 olcDbCancel: abandon olcDbChaseReferrals: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbNretries: 10 olcDbProtocolVersion: 3 olcDbRebindAsUser: FALSE olcDbSessionTrackingRequest: FALSE olcDbTFSupport: no structuralObjectClass: olcMetaConfig entryUUID: cf8afa3a-a284-4ac8-b60e-9431b0807ed4 creatorsName: cn=config createTimestamp: 20130430162302Z entryCSN: 20130430162302.509672Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20130430162302Z The fact is I don't have a metatarget configuration, because this is a subentry of olcDatabase={2}meta,cn=config, thus I must add the latter entry first. Also notice that I can't do a slapadd with just the meta configuration. (the ldif above). If I do this, I have an error : slapadd: could not add entry dn="olcDatabase={2}meta,cn=config" (line=1): autocreation of "olcDatabase={-1}frontend" failed I had to make a backup of the full configuration, and then add the meta configuration and import the resulting file.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2013