- openldap-bugs - openldap.org

(ITS#6487) Nssov pam_authz authorizedUserService
by crispy＠cluenet.org 04 Mar '10

04 Mar '10

Full_Name: Chris Breneman Version: 2.4.21 OS: Debian Lenny URL: http://paste.cluenet.org/pastebin.php?dl=2648 Submission from: (NULL) (98.212.227.43) My organization needs the capability of per-user (instead of per-group) access control with nssov. Using the method of modifying slapd ACLs to grant or revoke compare privileges on the authorizedService attribute of the host object is not scalable with large numbers of users, each of which have individual access. This patch adds an attribute "authorizedUserService" for use in a host entry. The attribute is in the form of "UID:SERVICE". If an attribute value for the user and service exists, access is granted. Otherwise access is denied. Wildcards in the form of "UID:*", "*:UID", and "*:*" are also supported. This patch also fixes a minor bug in the pam_authz function. Currently, one of the values read from NSCLD is used as a string in a Debug statement without initializing a NULL terminator. The patch extends the lengths of each buffer by 1 and initializes them to 0 so each buffer is always null-terminated and can be used as a string. The patch applies to the latest CVS HEAD as of this report, since several changes have been made in that region of code since 2.4.21. The patch is at http://paste.cluenet.org/pastebin.php?dl=2648 or http://paste.cluenet.org/2648

1 0

Re: (ITS#6485) nssov pam_authz fixes
by hyc＠symas.com 03 Mar '10

03 Mar '10

crispy(a)cluenet.org wrote: > Full_Name: Chris Breneman > Version: 2.4.21 > OS: Debian Lenny > URL: > Submission from: (NULL) (98.212.227.43) > > > In pam_authz(), in pam.c, in nssov, there are two problems: > > 1. Values in the service buffer are overwritten, and values in several other > buffers are never stored, preventing authorizedService checking from working. > 2. pam_authz() fails if nssov is not first used for authentication. Thanks for reporting these, fixes are in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6433) patch for the sha2 module: hash methods for passwords generation
by hyc＠symas.com 03 Mar '10

03 Mar '10

cdelfosse(a)mandriva.com wrote: > Full_Name: Cédric Delfosse > Version: HEAD > OS: Mandriva Linux > URL: ftp://ftp.openldap.org/incoming/cedric-delfosse-091221.patch > Submission from: (NULL) (62.212.120.90) > > > Hello, > > this patch allows to use the {SHA256}, {SHA384} and {SHA512} password schemes > (provided by the sha2 module) with LDAP Password Modify Extended Operations. > This patch contains the required hash methods. > > This patch file is derived from OpenLDAP Software. All of the modifications to > OpenLDAP Software represented in the following patch(es) were developed by > Mandriva. Mandriva has not assigned rights and/or interest in this work to any > party. I, Cédric Delfosse am authorized by Mandriva, my employer, to release > this work under the following terms. > > Mandriva 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. > > Regards, > > Cédric > Thanks, nice work. Committed in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6486) OpenLDAP Admin Guide Backends Documentation
by ryans＠aweber.com 03 Mar '10

03 Mar '10

Full_Name: Ryan Steele Version: 2.4.18 OS: Ubuntu Server URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (207.106.239.81) The Admin Guide section on backends is inconsistent in terms of specifying the moduleload statement, and whether or not it is required for any arbitrary backend. For example, the documentation on back-ldif explicitly states that it is not needed: >You'll notice that when compared to examples below, there is no: > > moduleload back_ldif.la > >directive. This is because back_ldif is always built in by default as it is used by >slapd-config(5), which again is built in by default. This is in contrast to the monitor backend configuration section where it is noted as being required: >You can however set a rootdn and rootpw. The following is all that is needed to >instantiate a monitor backend: > > include ./schema/core.schema > > modulepath /usr/local/libexec/openldap > moduleload back_monitor.la > > database monitor > rootdn "cn=monitoring,cn=Monitor" > rootpw monitoring Or, in the back-ldap configuration section, where mention is omitted entirely: > database ldap > suffix "dc=suretecsystems,dc=com" > rootdn "cn=slapd-ldap" > uri ldap://localhost/ ldap://remotehost ldap://remotehost2 I should note that this ITS is not referring sections in which the configuration section for a backend is missing entirely (such as back-meta), because IMHO the lack of information there precludes it from being subject to the aforementioned ambiguity. I made sure to check with #openldap on Freenode (2010-03-03, 14:05 EST) before submitting this ITS, and have made sure to obtain Howard's blessing: <hyc> go ahead and submit an ITS. I don't think you need to attach a patch. <hyc> probably we'll just add a bluurb at the top "if your installation uses dynamic modules, you may need to add the relevant moduleload directives to the following examples" <hyc> and leave it at that.

1 0

(ITS#6485) nssov pam_authz fixes
by crispy＠cluenet.org 02 Mar '10

02 Mar '10

Full_Name: Chris Breneman Version: 2.4.21 OS: Debian Lenny URL: Submission from: (NULL) (98.212.227.43) In pam_authz(), in pam.c, in nssov, there are two problems: 1. Values in the service buffer are overwritten, and values in several other buffers are never stored, preventing authorizedService checking from working. 2. pam_authz() fails if nssov is not first used for authentication.

1 0

(ITS#6484) slapd 2.4.21 + pcache + rwm coredump
by mhardin＠symas.com 02 Mar '10

02 Mar '10

Full_Name: Matt Hardin Version: 2.4.21 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (170.215.92.245) A naming context that uses back-ldap, slapo-rwm, and slapo-pcache dumps core when asked to perform an operation. Configuration snippets: database ldap suffix "dc=ad,dc=example,dc=com" subordinate rootdn "dc=ad,dc=example,dc=com" uri "ldaps://ldap01.example.com ldaps://ldap02.example.com" norefs yes chase-referrals no conn-ttl 300 network-timeout 10 use-temporary-conn yes # Identity assertion: connections authenticated as either of the two identities # below will connect to AD as the proxy user. Connections authenticated as # anything else (i.e., AD users) use those credentials for authentication. idassert-bind bindmethod=simple binddn="cn=cnsproxy,dc=example,dc=com" credentials=xxxxxx mode=legacy flags=override idassert-authzFrom "dn.regex:cn=proxy,dc=example,dc=com" # It is necessary to map a number of objectclass and attribute names to # various other names that are supported in RFC2307. We also take this # opportunity to 'lose' certain other attributes that have no place in # UNIX. overlay rwm rwm-normalize-mapped-attrs yes rwm-suffixmassage "dc=ad,dc=example,dc=com" "dc=example,dc=com" rwm-map objectClass posixAccount user rwm-map attribute uid samAccountName rwm-map attribute "" gecos [lots of rwm-map statements removed] # Caching setup overlay pcache proxycache hdb 100000 2 10000 50000 proxycachequeries 20000 proxyattrset 0 uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass memberUid member proxyattrset 1 * # proxytemplate (&(objectClass=)(uid=)) 0 3600 300 proxytemplate (&(objectClass=)(uid=)) 1 3600 300 proxytemplate (&(objectClass=)(uidNumber=)) 0 3600 300 proxytemplate (&(objectClass=)(member=)) 0 3600 300 proxytemplate (&(objectClass=)(|(memberUid=)(member=))) 0 3600 300 proxytemplate (uid=) 0 3600 300 proxytemplate (&(objectClass=)(cn=)) 0 3600 300 proxytemplate (&(objectClass=)(gidNumber=)) 0 3600 300 proxytemplate (objectClass=*) 0 3600 300 # directory /var/symas/openldap-data/example-pcache cachesize 10000 idlcachesize 10000 checkpoint 512 600 sizelimit unlimited index objectClass eq index cn,sn,uid eq index uidNumber eq index gidNumber eq index memberUid eq index member eq index queryid eq dbconfig set_cachesize 0 536870912 0 dbconfig set_flags DB_LOG_AUTOREMOVE dbconfig set_lg_max 10485760 dbconfig set_lg_bsize 2097152 Backtrace is as follows: (gdb) thr apply all bt Thread 5 (process 19756): #0 0x0083d7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00abc297 in pthread_join () from /lib/tls/libpthread.so.0 #2 0x00608524 in ldap_pvt_thread_join (thread=4294967292, thread_return=0xfffffffc) at /home/build/sol-2.4.21.0/sol24x/ldap24/libraries/libldap_r/thr_posix.c:197 #3 0x0806f48a in slapd_daemon () at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/daemon.c:2840 #4 0x0805896d in main (argc=7, argv=0xbfe4d694) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/main.c:961 Thread 4 (process 19757): #0 0x0083d7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x0070a1ce in epoll_wait () from /lib/tls/libc.so.6 #2 0x0806e505 in slapd_daemon_task (ptr=0x0) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/daemon.c:2465 #3 0x00abb3cc in start_thread () from /lib/tls/libpthread.so.0 #4 0x00709b4e in clone () from /lib/tls/libc.so.6 Thread 3 (process 19759): #0 0x0083d7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00abdcf6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 #2 0x00608664 in ldap_pvt_thread_cond_wait (cond=0xfffffffc, mutex=0xfffffffc) at /home/build/sol-2.4.21.0/sol24x/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00607822 in ldap_int_thread_pool_wrapper (xpool=0x82c56f0) at /home/build/sol-2.4.21.0/sol24x/ldap24/libraries/libldap_r/tpool.c:672 #4 0x00abb3cc in start_thread () from /lib/tls/libpthread.so.0 ---Type <return> to continue, or q <return> to quit--- #5 0x00709b4e in clone () from /lib/tls/libc.so.6 Thread 2 (process 19760): #0 0x0083d7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00abdcf6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 #2 0x00608664 in ldap_pvt_thread_cond_wait (cond=0xfffffffc, mutex=0xfffffffc) at /home/build/sol-2.4.21.0/sol24x/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00607822 in ldap_int_thread_pool_wrapper (xpool=0x82c56f0) at /home/build/sol-2.4.21.0/sol24x/ldap24/libraries/libldap_r/tpool.c:672 #4 0x00abb3cc in start_thread () from /lib/tls/libpthread.so.0 #5 0x00709b4e in clone () from /lib/tls/libc.so.6 Thread 1 (process 19758): #0 0x0083d7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00665825 in raise () from /lib/tls/libc.so.6 #2 0x00667289 in abort () from /lib/tls/libc.so.6 #3 0x0065eda1 in __assert_fail () from /lib/tls/libc.so.6 #4 0x0807bc34 in entry_clean (e=0x835ccdc) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/entry.c:483 #5 0x0807bc52 in entry_free (e=0x835ccdc) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/entry.c:514 #6 0x080da90e in overlay_entry_release_ov (op=0x838b5a0, e=0x835ccdc, rw=0, on=0x82fcb50) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/backover.c:439 #7 0x0093aa55 in rwm_send_entry (op=0x838b5a0, rs=0x3a1a100) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/overlays/rwm.c:1508 #8 0x0093b129 in rwm_response (op=0x838b5a0, rs=0x6) ---Type <return> to continue, or q <return> to quit--- at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/overlays/rwm.c:1700 #9 0x080da44a in over_back_response (op=0x838b5a0, rs=0x3a1a100) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/backover.c:237 #10 0x08081be0 in slap_response_play (op=0x838b5a0, rs=0x3a1a100) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/result.c:358 #11 0x0808439b in slap_send_search_entry (op=0x838b5a0, rs=0x3a1a100) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/result.c:843 #12 0x00bd8005 in hdb_search (op=0x838b5a0, rs=0x3a1a100) at search.c:961 #13 0x00a7d495 in pcache_op_search (op=0x838b5a0, rs=0x3a1a100) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/overlays/pcache.c:3029 #14 0x080dad59 in overlay_op_walk (op=0x838b5a0, rs=0x3a1a100, which=op_search, oi=0x82fca50, on=0x8303408) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/backover.c:659 #15 0x080daebc in over_op_func (op=0x838b5a0, rs=0x3a1a100, which=op_search) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/backover.c:721 #16 0x080d8f18 in glue_op_search (op=0x838b5a0, rs=0x3a1a100) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/backglue.c:457 #17 0x080dad59 in overlay_op_walk (op=0x838b5a0, rs=0x3a1a100, which=op_search, oi=0x8302778, on=0x8302878) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/backover.c:659 #18 0x080daebc in over_op_func (op=0x838b5a0, rs=0x3a1a100, which=op_search) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/backover.c:721 #19 0x08074b36 in fe_op_search (op=0x838b5a0, rs=0x3a1a100) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/search.c:366 #20 0x08074041 in do_search (op=0x838b5a0, rs=0x3a1a100) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/search.c:217 #21 0x08072205 in connection_operation (ctx=0x3a1a210, arg_v=0x838b5a0) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/connection.c:1109 ---Type <return> to continue, or q <return> to quit--- #22 0x08072b54 in connection_read_thread (ctx=0x3a1a210, argv=0x18) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/connection.c:1245 #23 0x006077c6 in ldap_int_thread_pool_wrapper (xpool=0x82c56f0) at /home/build/sol-2.4.21.0/sol24x/ldap24/libraries/libldap_r/tpool.c:685 #24 0x00abb3cc in start_thread () from /lib/tls/libpthread.so.0 #25 0x00709b4e in clone () from /lib/tls/libc.so.6 (gdb) q Commentary from debugging session: the entry in question is owned by pcache's cache DB and the overlay_entry_release() function didn't fall into the right release hook because the pcache overlay didn't provide one so this has to be fixed by adding a release hook to pcache not a big deal. so the fault isn't in rwm this time, it's calling the right API

1 0

Re: (ITS#6055) Re: Samba4 need 'name' implementation like AD (RDN-Name)
by abartlet＠samba.org 01 Mar '10

01 Mar '10

--=-wu98lDL/cs9xvAtVkpXf Content-Type: multipart/mixed; boundary="=-bGZqaJas0lpiam3pf2jA" --=-bGZqaJas0lpiam3pf2jA Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2010-03-02 at 15:30 +1100, Andrew Bartlett wrote: > On Mon, 2009-08-03 at 20:44 +0200, masarati(a)aero.polimi.it wrote: > > [Resending because I forgot the ITS number in the subject] > >=20 > > I have a simple prototype that on add/modrdn populates/maintains an > > attribute (rdnValue) with the distinguished values of the naming > > attributes of the RDN. While doing this, it also checks for uniqueness= of > > the rdnValue value within siblings. > >=20 > > You can find it here > > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2009-08-03-rdnval.= 2.c> > >=20 > > Please test and comment. I hope it does what intended. >=20 > I'm starting to look at this now. I'm sorry so many months have past > since you posted it. I've now added it into Samba's provision, and using the diff I attach, against current 'master', I get the attached error. It seems to be unable to add the base DN. (The very first entry in the database). Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. --=-bGZqaJas0lpiam3pf2jA Content-Disposition: attachment; filename="rdnval-use-in-samba.diff" Content-Transfer-Encoding: base64 Content-Type: text/x-patch; name="rdnval-use-in-samba.diff"; charset="UTF-8" ZGlmZiAtLWdpdCBhL3NvdXJjZTQvZHNkYi9zYW1kYi9sZGJfbW9kdWxlcy9zYW1iYV9kc2RiLmMg Yi9zb3VyY2U0L2RzZGIvc2FtZGIvbGRiX21vZHVsZXMvc2FtYmFfZHNkYi5jDQppbmRleCBjOTI5 ZDY1Li5jOGQ1YjkzIDEwMDY0NA0KLS0tIGEvc291cmNlNC9kc2RiL3NhbWRiL2xkYl9tb2R1bGVz L3NhbWJhX2RzZGIuYw0KKysrIGIvc291cmNlNC9kc2RiL3NhbWRiL2xkYl9tb2R1bGVzL3NhbWJh X2RzZGIuYw0KQEAgLTE3NSw3ICsxNzUsNiBAQCBzdGF0aWMgaW50IHNhbWJhX2RzZGJfaW5pdChz dHJ1Y3QgbGRiX21vZHVsZSAqbW9kdWxlKQ0KIAkJCQkJICAgICAiYXNxIiwNCiAJCQkJCSAgICAg ImV4dGVuZGVkX2RuX3N0b3JlIiwNCiAJCQkJCSAgICAgImV4dGVuZGVkX2RuX2luIiwNCi0JCQkJ CSAgICAgInJkbl9uYW1lIiwNCiAJCQkJCSAgICAgIm9iamVjdGNsYXNzIiwNCiAJCQkJCSAgICAg ImRlc2NyaXB0b3IiLA0KIAkJCQkJICAgICAiYWNsIiwNCkBAIC0xOTEsNiArMTkwLDcgQEAgc3Rh dGljIGludCBzYW1iYV9kc2RiX2luaXQoc3RydWN0IGxkYl9tb2R1bGUgKm1vZHVsZSkNCiAJY29u c3QgY2hhciAqKmxpbmtfbW9kdWxlczsNCiAJc3RhdGljIGNvbnN0IGNoYXIgKnRkYl9tb2R1bGVz X2xpc3RbXSA9IHsNCiAJCSJzdWJ0cmVlX2RlbGV0ZSIsDQorCQkicmRuX25hbWUiLA0KIAkJInJl cGxfbWV0YV9kYXRhIiwNCiAJCSJzdWJ0cmVlX3JlbmFtZSIsDQogCQkibGlua2VkX2F0dHJpYnV0 ZXMiLA0KZGlmZiAtLWdpdCBhL3NvdXJjZTQvZHNkYi9zYW1kYi9sZGJfbW9kdWxlcy9zaW1wbGVf bGRhcF9tYXAuYyBiL3NvdXJjZTQvZHNkYi9zYW1kYi9sZGJfbW9kdWxlcy9zaW1wbGVfbGRhcF9t YXAuYw0KaW5kZXggYmY5Y2Q0Zi4uNWVjN2E0YSAxMDA2NDQNCi0tLSBhL3NvdXJjZTQvZHNkYi9z YW1kYi9sZGJfbW9kdWxlcy9zaW1wbGVfbGRhcF9tYXAuYw0KKysrIGIvc291cmNlNC9kc2RiL3Nh bWRiL2xkYl9tb2R1bGVzL3NpbXBsZV9sZGFwX21hcC5jDQpAQCAtMjg3LDcgKzI4Nyw3IEBAIHN0 YXRpYyBjb25zdCBzdHJ1Y3QgbGRiX21hcF9hdHRyaWJ1dGUgZW50cnl1dWlkX2F0dHJpYnV0ZXNb XSA9DQogCQkudHlwZSA9IExEQl9NQVBfUkVOQU1FLA0KIAkJLnUgPSB7DQogCQkJLnJlbmFtZSA9 IHsNCi0JCQkJIC5yZW1vdGVfbmFtZSA9ICJzYW1iYTRSRE4iDQorCQkJCSAucmVtb3RlX25hbWUg PSAicmRudmFsIg0KIAkJCSB9DQogCQl9DQogCX0sDQpkaWZmIC0tZ2l0IGEvc291cmNlNC9zZXR1 cC9zY2hlbWEtbWFwLW9wZW5sZGFwLTIuMyBiL3NvdXJjZTQvc2V0dXAvc2NoZW1hLW1hcC1vcGVu bGRhcC0yLjMNCmluZGV4IDBkMzg2NTIuLmFlZDU0MDIgMTAwNjQ0DQotLS0gYS9zb3VyY2U0L3Nl dHVwL3NjaGVtYS1tYXAtb3BlbmxkYXAtMi4zDQorKysgYi9zb3VyY2U0L3NldHVwL3NjaGVtYS1t YXAtb3BlbmxkYXAtMi4zDQpAQCAtMTUsNiArMTUsOSBAQCB1aWROdW1iZXINCiBnaWROdW1iZXIN CiAjVGhlIG1lbWJlck9mIHBsdWdpbiBwcm92aWRlcyB0aGlzIGF0dHJpYnV0ZQ0KIG1lbWJlck9m DQorIyduYW1lJyBpcyB0aGUgUkROIGluIEFELCBidXQgc29tZXRoaW5nIGVsc2UgaW4gT3BlbkxE QVAuICBTa2lwIGFuZA0KKyMgdXNlIHRoZSBPcGVuTERBUCBvbmUNCituYW1lDQogI1RoZXNlIGNv bmZsaWN0IHdpdGggT3BlbkxEQVAgYnVpbHRpbnMNCiBhdHRyaWJ1dGVUeXBlczpzYW1iYTRBdHRy aWJ1dGVUeXBlcw0KIDIuNS4yMS41OjEuMy42LjEuNC4xLjcxNjUuNC4yNTUuNw0KQEAgLTI0LDgg KzI3LDYgQEAgb2JqZWN0Q2xhc3NlczpzYW1iYTRPYmplY3RDbGFzc2VzDQogMi41LjIxLjY6MS4z LjYuMS40LjEuNzE2NS40LjI1NS41DQogc3ViU2NoZW1hOnNhbWJhNFN1YlNjaGVtYQ0KIDIuNS4y MC4xOjEuMy42LjEuNC4xLjcxNjUuNC4yNTUuNA0KLSMnbmFtZScgaXMgdGhlIFJETiBpbiBBRCwg YnV0IHNvbWV0aGluZyBlbHNlIGluIE9wZW5MREFQDQotbmFtZTpzYW1iYTRSRE4NCiAjUmVtYXAg dGhlc2Ugc28gdGhhdCB3ZSBkb24ndCBwdXQgb3BlcmF0aW9uYWwgYXR0cmlidXRlcyBpbiBhIHNj aGVtYSBNQVkNCiBtb2RpZnlUaW1lU3RhbXA6c2FtYmE0TW9kaWZ5VGltZXN0YW1wDQogMi41LjE4 LjI6MS4zLjYuMS40LjEuNzE2NS40LjI1NS4zDQpkaWZmIC0tZ2l0IGEvc291cmNlNC9zZXR1cC9z bGFwZC5jb25mIGIvc291cmNlNC9zZXR1cC9zbGFwZC5jb25mDQppbmRleCAwMDc3YTIyLi5lNWZj ZDA2IDEwMDY0NA0KLS0tIGEvc291cmNlNC9zZXR1cC9zbGFwZC5jb25mDQorKysgYi9zb3VyY2U0 L3NldHVwL3NsYXBkLmNvbmYNCkBAIC00OSw2ICs0OSw3IEBAIGRlZmF1bHRzZWFyY2hiYXNlICR7 RE9NQUlORE59DQogcm9vdGRuIGNuPU1hbmFnZXINCiANCiBvdmVybGF5IGRlcmVmDQorb3Zlcmxh eSByZG52YWwNCiANCiAke1JFRklOVF9DT05GSUd9DQogDQo= --=-bGZqaJas0lpiam3pf2jA Content-Disposition: attachment; filename="rdnval-errors.txt" Content-Transfer-Encoding: base64 Content-Type: text/plain; name="rdnval-errors.txt"; charset="UTF-8" PT4gZ2V0X2N0cmxzDQpiZXJfc2NhbmYgZm10ICh7bSkgYmVyOg0KYmVyX2R1bXA6IGJ1Zj0weDE2 MjlmMjAgcHRyPTB4MTYyYTkwMSBlbmQ9MHgxNjJhOTFlIGxlbj0yOQ0KICAwMDAwOiAgMzAgMWIg MDQgMTkgMzEgMmUgMzMgMmUgIDM2IDJlIDMxIDJlIDM0IDJlIDMxIDJlICAgMC4uLjEuMy42LjEu NC4xLiAgDQogIDAwMTA6ICAzNCAzMiAzMCAzMyAyZSAzNiAzNiAzNiAgMmUgMzUgMmUgMzEgMzIg ICAgICAgICAgICA0MjAzLjY2Ni41LjEyICAgICANCj0+IGdldF9jdHJsczogb2lkPSIxLjMuNi4x LjQuMS40MjAzLjY2Ni41LjEyIiAobm9uY3JpdGljYWwpDQo8PSBnZXRfY3RybHM6IG49MSByYz0w IGVycj0iIg0KPj4+IGRuUHJldHR5Tm9ybWFsOiA8REM9c2FtYmEsREM9ZXhhbXBsZSxEQz1jb20+ DQo9PiBsZGFwX2J2MmRuKERDPXNhbWJhLERDPWV4YW1wbGUsREM9Y29tLDApDQo8PSBsZGFwX2J2 MmRuKERDPXNhbWJhLERDPWV4YW1wbGUsREM9Y29tKT0wIA0KPT4gbGRhcF9kbjJidigyNzIpDQo8 PSBsZGFwX2RuMmJ2KGRjPXNhbWJhLGRjPWV4YW1wbGUsZGM9Y29tKT0wIA0KPT4gbGRhcF9kbjJi digyNzIpDQo8PSBsZGFwX2RuMmJ2KGRjPXNhbWJhLGRjPWV4YW1wbGUsZGM9Y29tKT0wIA0KPDw8 IGRuUHJldHR5Tm9ybWFsOiA8ZGM9c2FtYmEsZGM9ZXhhbXBsZSxkYz1jb20+LCA8ZGM9c2FtYmEs ZGM9ZXhhbXBsZSxkYz1jb20+DQpjb25uPTEwMDEgb3A9NSBBREQgZG49ImRjPXNhbWJhLGRjPWV4 YW1wbGUsZGM9Y29tIg0KPj4+IGRuUHJldHR5OiA8Q049RG9tYWluLUROUyxDTj1TY2hlbWEsQ049 Q29uZmlndXJhdGlvbixEQz1zYW1iYSxEQz1leGFtcGxlLERDPWNvbT4NCj0+IGxkYXBfYnYyZG4o Q049RG9tYWluLUROUyxDTj1TY2hlbWEsQ049Q29uZmlndXJhdGlvbixEQz1zYW1iYSxEQz1leGFt cGxlLERDPWNvbSwwKQ0KPD0gbGRhcF9idjJkbihDTj1Eb21haW4tRE5TLENOPVNjaGVtYSxDTj1D b25maWd1cmF0aW9uLERDPXNhbWJhLERDPWV4YW1wbGUsREM9Y29tKT0wIA0KPT4gbGRhcF9kbjJi digyNzIpDQo8PSBsZGFwX2RuMmJ2KGNuPURvbWFpbi1ETlMsY249U2NoZW1hLGNuPUNvbmZpZ3Vy YXRpb24sZGM9c2FtYmEsZGM9ZXhhbXBsZSxkYz1jb20pPTAgDQo8PDwgZG5QcmV0dHk6IDxjbj1E b21haW4tRE5TLGNuPVNjaGVtYSxjbj1Db25maWd1cmF0aW9uLGRjPXNhbWJhLGRjPWV4YW1wbGUs ZGM9Y29tPg0KPj4+IGRuTm9ybWFsaXplOiA8Y249RG9tYWluLUROUyxjbj1TY2hlbWEsY249Q29u ZmlndXJhdGlvbixkYz1zYW1iYSxkYz1leGFtcGxlLGRjPWNvbT4NCj0+IGxkYXBfYnYyZG4oY249 RG9tYWluLUROUyxjbj1TY2hlbWEsY249Q29uZmlndXJhdGlvbixkYz1zYW1iYSxkYz1leGFtcGxl LGRjPWNvbSwwKQ0KPD0gbGRhcF9idjJkbihjbj1Eb21haW4tRE5TLGNuPVNjaGVtYSxjbj1Db25m aWd1cmF0aW9uLGRjPXNhbWJhLGRjPWV4YW1wbGUsZGM9Y29tKT0wIA0KPT4gbGRhcF9kbjJidigy NzIpDQo8PSBsZGFwX2RuMmJ2KGNuPWRvbWFpbi1kbnMsY249c2NoZW1hLGNuPWNvbmZpZ3VyYXRp b24sZGM9c2FtYmEsZGM9ZXhhbXBsZSxkYz1jb20pPTAgDQo8PDwgZG5Ob3JtYWxpemU6IDxjbj1k b21haW4tZG5zLGNuPXNjaGVtYSxjbj1jb25maWd1cmF0aW9uLGRjPXNhbWJhLGRjPWV4YW1wbGUs ZGM9Y29tPg0Kc3RyMmZpbHRlciAiKHJkblZhbHVlPXNhbWJhKSINCnB1dF9maWx0ZXI6ICIocmRu VmFsdWU9c2FtYmEpIg0KcHV0X2ZpbHRlcjogc2ltcGxlDQpwdXRfc2ltcGxlX2ZpbHRlcjogInJk blZhbHVlPXNhbWJhIg0KYmVnaW4gZ2V0X2ZpbHRlcg0KRVFVQUxJVFkNCmJlcl9zY2FuZiBmbXQg KHttbX0pIGJlcjoNCmJlcl9kdW1wOiBidWY9MHg3ZjQ2Y2M4NzgxZjggcHRyPTB4N2Y0NmNjODc4 MWY4IGVuZD0weDdmNDZjYzg3ODIwYiBsZW49MTkNCiAgMDAwMDogIGEzIDExIDA0IDA4IDcyIDY0 IDZlIDU2ICA2MSA2YyA3NSA2NSAwNCAwNSA3MyA2MSAgIC4uLi5yZG5WYWx1ZS4uc2EgIA0KICAw MDEwOiAgNmQgNjIgNjEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg bWJhICAgICAgICAgICAgICAgDQplbmQgZ2V0X2ZpbHRlciAwDQpzZW5kX2xkYXBfcmVzdWx0OiBj b25uPTEwMDEgb3A9NSBwPTMNCnNlbmRfbGRhcF9yZXN1bHQ6IGVycj0xMCBtYXRjaGVkPSIiIHRl eHQ9IiINCnNlbmRfbGRhcF9yZXN1bHQ6IGNvbm49MTAwMSBvcD01IHA9Mw0Kc2VuZF9sZGFwX3Jl c3VsdDogZXJyPTE5IG1hdGNoZWQ9IiIgdGV4dD0icmRuVmFsdWUgbm90IHVuaXF1ZSB3aXRoaW4g c2libGluZ3MiDQpzZW5kX2xkYXBfcmVzcG9uc2U6IG1zZ2lkPTYgdGFnPTEwNSBlcnI9MTkNCmJl cl9mbHVzaDI6IDQ5IGJ5dGVzIHRvIHNkIDIxDQogIDAwMDA6ICAzMCAyZiAwMiAwMSAwNiA2OSAy YSAwYSAgMDEgMTMgMDQgMDAgMDQgMjMgNzIgNjQgICAwLy4uLmkqLi4uLi4uI3JkICANCiAgMDAx MDogIDZlIDU2IDYxIDZjIDc1IDY1IDIwIDZlICA2ZiA3NCAyMCA3NSA2ZSA2OSA3MSA3NSAgIG5W YWx1ZSBub3QgdW5pcXUgIA0KICAwMDIwOiAgNjUgMjAgNzcgNjkgNzQgNjggNjkgNmUgIDIwIDcz IDY5IDYyIDZjIDY5IDZlIDY3ICAgZSB3aXRoaW4gc2libGluZyAgDQogIDAwMzA6ICA3MyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzICAgICAgICAgICAg ICAgICANCmxkYXBfd3JpdGU6IHdhbnQ9NDksIHdyaXR0ZW49NDkNCiAgMDAwMDogIDMwIDJmIDAy IDAxIDA2IDY5IDJhIDBhICAwMSAxMyAwNCAwMCAwNCAyMyA3MiA2NCAgIDAvLi4uaSouLi4uLi4j cmQgIA0KICAwMDEwOiAgNmUgNTYgNjEgNmMgNzUgNjUgMjAgNmUgIDZmIDc0IDIwIDc1IDZlIDY5 IDcxIDc1ICAgblZhbHVlIG5vdCB1bmlxdSAgDQogIDAwMjA6ICA2NSAyMCA3NyA2OSA3NCA2OCA2 OSA2ZSAgMjAgNzMgNjkgNjIgNmMgNjkgNmUgNjcgICBlIHdpdGhpbiBzaWJsaW5nICANCiAgMDAz MDogIDczICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHMg ICAgICAgICAgICAgICAgIA0KY29ubj0xMDAxIG9wPTUgUkVTVUxUIHRhZz0xMDUgZXJyPTE5IHRl eHQ9cmRuVmFsdWUgbm90IHVuaXF1ZSB3aXRoaW4gc2libGluZ3MNClRyYWNlYmFjayAobW9zdCBy ZWNlbnQgY2FsbCBsYXN0KToNCiAgRmlsZSAiLi9zZXR1cC9wcm92aXNpb24iLCBsaW5lIDI0NSwg aW4gPG1vZHVsZT4NCiAgICBub3N5bmM9b3B0cy5ub3N5bmMsbGRhcF9kcnlydW5fbW9kZT1vcHRz LmxkYXBfZHJ5cnVuX21vZGUsdXNlZWFkYj1lYWRiKQ0KICBGaWxlICJiaW4vcHl0aG9uL3NhbWJh L3Byb3Zpc2lvbi5weSIsIGxpbmUgMTMwNSwgaW4gcHJvdmlzaW9uDQogICAgZG9tX2Zvcl9mdW5f bGV2ZWw9ZG9tX2Zvcl9mdW5fbGV2ZWwpDQogIEZpbGUgImJpbi9weXRob24vc2FtYmEvcHJvdmlz aW9uLnB5IiwgbGluZSA5MTIsIGluIHNldHVwX3NhbWRiDQogICAgIkRFU0NSSVBUT1IiOiBkZXNj cg0KICBGaWxlICJiaW4vcHl0aG9uL3NhbWJhL3Byb3Zpc2lvbi5weSIsIGxpbmUgMjM5LCBpbiBz ZXR1cF9hZGRfbGRpZg0KICAgIGxkYi5hZGRfbGRpZihkYXRhLGNvbnRyb2xzKQ0KICBGaWxlICJi aW4vcHl0aG9uL3NhbWJhL19faW5pdF9fLnB5IiwgbGluZSAyNTgsIGluIGFkZF9sZGlmDQogICAg c2VsZi5hZGQobXNnLGNvbnRyb2xzKQ0KX2xkYi5MZGJFcnJvcjogKDE5LCAnTERBUCBlcnJvciAx OSBMREFQX0NPTlNUUkFJTlRfVklPTEFUSU9OIC0gIDxyZG5WYWx1ZSBub3QgdW5pcXVlIHdpdGhp biBzaWJsaW5ncz4gPD4nKQ0K --=-bGZqaJas0lpiam3pf2jA-- --=-wu98lDL/cs9xvAtVkpXf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQBLjLtkz4A8Wyi0NrsRApu+AJ0cW7Vd8zPhS57s8r+iW3D5lFbNHQCgkYCP vgrrkMMEYjbxPtMqqgUHbrY= =ZH85 -----END PGP SIGNATURE----- --=-wu98lDL/cs9xvAtVkpXf--

1 0

Re: (ITS#6055) Re: Samba4 need 'name' implementation like AD (RDN-Name)
by abartlet＠samba.org 01 Mar '10

01 Mar '10

--=-3cgveKzr2Byp6ib+VYg9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2009-08-03 at 20:44 +0200, masarati(a)aero.polimi.it wrote: > [Resending because I forgot the ITS number in the subject] >=20 > I have a simple prototype that on add/modrdn populates/maintains an > attribute (rdnValue) with the distinguished values of the naming > attributes of the RDN. While doing this, it also checks for uniqueness o= f > the rdnValue value within siblings. >=20 > You can find it here > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2009-08-03-rdnval.2.= c> >=20 > Please test and comment. I hope it does what intended. I'm starting to look at this now. I'm sorry so many months have past since you posted it. Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. --=-3cgveKzr2Byp6ib+VYg9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQBLjJRvz4A8Wyi0NrsRAqh2AJ4uvpxIGj0PTacpWVLVO18BRrWqaQCeOqhh VdZtFVltm6uv6qY3Lw7ULpk= =zoZi -----END PGP SIGNATURE----- --=-3cgveKzr2Byp6ib+VYg9--

1 0

Status of ITS 5941?
by Lars Kellogg-Stedman 01 Mar '10

01 Mar '10

Hello all, I think I've just run into ITS 5941 (http://www.openldap.org/its/index.cgi/Software%20Bugs?id=5941). I'm trying to set up a proxy using the "translucent" overlay in front of an Active Directory server; I'd like to rewrite some attributes (e.g., sAMAccountName -> uid) as part of this process. The config looks like this: moduleload translucent moduleload rwm database ldif suffix "dc=dept,dc=example,dc=com" directory "/var/lib/ldap/ad-proxy" rootdn "cn=admin,dc=dept,dc=example,dc=com" rootpw "password" overlay translucent uri ldap://127.0.0.1/ acl-bind bindmethod=simple binddn=cn=binduser,ou=people,cn=admin,dc=dept,dc=example,dc=com credentials=password overlay rwm rwm-map attribute uid sAMAccountName With this configuration in place, I can complete one search, after which slapd dies with: Segmentation fault If I explicitly request the rewritten attribute: $ ldapsearch ... cn=lars uid Slapd dies with a backtrace: *** glibc detected *** slapd: double free or corruption (!prev): 0xb6602320 *** ======= Backtrace: ========= /lib/libc.so.6(+0x1b7751)[0x858751] slapd(ber_memfree_x+0x50)[0x610c40] slapd(slap_sl_free+0x70)[0x527240] slapd(do_search+0x17f)[0x4c819f] slapd(+0x3c15e)[0x4c515e] slapd(+0x15921c)[0x5e221c] /lib/libpthread.so.0(+0x2f8ab5)[0x334ab5] /lib/libc.so.6(clone+0x5e)[0x8c4dce] Does this look like the same problem? Is there a fix available? If not, is there a workaround that doesn't involve running a second instance of slapd as a rewriting proxy?

1 0

(ITS#6483) [PATCH] Properly use #elif
by delphij＠FreeBSD.org 01 Mar '10

01 Mar '10

Full_Name: Xin LI Version: -HEAD OS: FreeBSD/amd64 URL: http://people.freebsd.org/~delphij/misc/openldap-elif.diff Submission from: (NULL) (206.40.55.65) OpenLDAP uses several #elif to test if a macro is being defined, which should be spelled as #elif defined. Here is a patch against CVS -HEAD. Index: include/ac/regex.h =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/include/ac/regex.h,v retrieving revision 1.20 diff -u -p -u -p -r1.20 regex.h --- include/ac/regex.h 21 Jan 2009 23:40:18 -0000 1.20 +++ include/ac/regex.h 1 Mar 2010 20:12:52 -0000 @@ -28,7 +28,7 @@ */ #error "No POSIX REGEX available." -#elif HAVE_GNUREGEX_H +#elif defined(HAVE_GNUREGEX_H) /* system has GNU gnuregex.h */ # include <gnuregex.h> #else Index: include/ac/signal.h =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/include/ac/signal.h,v retrieving revision 1.28 diff -u -p -u -p -r1.28 signal.h --- include/ac/signal.h 21 Jan 2009 23:40:18 -0000 1.28 +++ include/ac/signal.h 1 Mar 2010 20:12:52 -0000 @@ -72,7 +72,7 @@ LDAP_LUTIL_F(lutil_sig_t) lutil_sigactio #ifndef LDAP_SIGCHLD #ifdef SIGCHLD #define LDAP_SIGCHLD SIGCHLD -#elif SIGCLD +#elif defined(SIGCLD) #define LDAP_SIGCHLD SIGCLD #endif #endif Index: include/ac/socket.h =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/include/ac/socket.h,v retrieving revision 1.77 diff -u -p -u -p -r1.77 socket.h --- include/ac/socket.h 23 Oct 2009 10:29:50 -0000 1.77 +++ include/ac/socket.h 1 Mar 2010 20:12:52 -0000 @@ -62,7 +62,7 @@ #ifdef HAVE_WINSOCK2 #include <winsock2.h> -#elif HAVE_WINSOCK +#elif defined(HAVE_WINSOCK) #include <winsock.h> #endif @@ -110,12 +110,12 @@ LBER_F( char * ) ber_pvt_wsa_err2string LDAP_P((int)); -#elif MACOS +#elif defined(MACOS) # define tcp_close( s ) tcpclose( s ) # define tcp_read( s, buf, len ) tcpread( s, buf, len ) # define tcp_write( s, buf, len ) tcpwrite( s, buf, len ) -#elif DOS +#elif defined(DOS) # ifdef PCNFS # define tcp_close( s ) close( s ) # define tcp_read( s, buf, len ) recv( s, buf, len, 0 ) Index: libraries/liblber/nt_err.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/libraries/liblber/nt_err.c,v retrieving revision 1.18 diff -u -p -u -p -r1.18 nt_err.c --- libraries/liblber/nt_err.c 21 Jan 2009 23:40:19 -0000 1.18 +++ libraries/liblber/nt_err.c 1 Mar 2010 20:12:52 -0000 @@ -17,7 +17,7 @@ #ifdef HAVE_WINSOCK2 #include <winsock2.h> -#elif HAVE_WINSOCK +#elif defined(HAVE_WINSOCK) #include <winsock.h> #endif /* HAVE_WINSOCK(2) */ Index: libraries/libldap/init.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/libraries/libldap/init.c,v retrieving revision 1.123 diff -u -p -u -p -r1.123 init.c --- libraries/libldap/init.c 15 Nov 2009 20:48:49 -0000 1.123 +++ libraries/libldap/init.c 1 Mar 2010 20:12:52 -0000 @@ -616,7 +616,7 @@ void ldap_int_initialize( struct ldapopt return; } } /* The WinSock DLL is acceptable. Proceed. */ -#elif HAVE_WINSOCK +#elif defined(HAVE_WINSOCK) { WSADATA wsaData; if ( WSAStartup( 0x0101, &wsaData ) != 0 ) { return; Index: libraries/liblutil/detach.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/libraries/liblutil/detach.c,v retrieving revision 1.22 diff -u -p -u -p -r1.22 detach.c --- libraries/liblutil/detach.c 21 Jan 2009 23:40:23 -0000 1.22 +++ libraries/liblutil/detach.c 1 Mar 2010 20:12:52 -0000 @@ -128,7 +128,7 @@ lutil_detach( int debug, int do_close ) #ifdef HAVE_SETSID (void) setsid(); -#elif TIOCNOTTY +#elif defined(TIOCNOTTY) if ( (sd = open( "/dev/tty", O_RDWR )) != -1 ) { (void) ioctl( sd, TIOCNOTTY, NULL ); (void) close( sd ); Index: libraries/liblutil/entropy.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/libraries/liblutil/entropy.c,v retrieving revision 1.32 diff -u -p -u -p -r1.32 entropy.c --- libraries/liblutil/entropy.c 21 Jan 2009 23:40:23 -0000 1.32 +++ libraries/liblutil/entropy.c 1 Mar 2010 20:12:52 -0000 @@ -73,7 +73,7 @@ int lutil_entropy( unsigned char *buf, b close(fd); return nbytes > 0 ? -1 : 0; } -#elif PROV_RSA_FULL +#elif defined(PROV_RSA_FULL) { /* Not used since _WIN32_WINNT not set... */ HCRYPTPROV hProv = 0; [delphij@delta] ~/scratch/oo/ldap-src> cvs -qR diff -uNp > ~/openldap-elif.diff [delphij@delta] ~/scratch/oo/ldap-src> cat ~/open openldap-elif.diff openvpn.conf [delphij@delta] ~/scratch/oo/ldap-src> cat ~/openldap-elif.diff Index: include/ac/regex.h =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/include/ac/regex.h,v retrieving revision 1.20 diff -u -p -u -p -r1.20 regex.h --- include/ac/regex.h 21 Jan 2009 23:40:18 -0000 1.20 +++ include/ac/regex.h 1 Mar 2010 20:13:03 -0000 @@ -28,7 +28,7 @@ */ #error "No POSIX REGEX available." -#elif HAVE_GNUREGEX_H +#elif defined(HAVE_GNUREGEX_H) /* system has GNU gnuregex.h */ # include <gnuregex.h> #else Index: include/ac/signal.h =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/include/ac/signal.h,v retrieving revision 1.28 diff -u -p -u -p -r1.28 signal.h --- include/ac/signal.h 21 Jan 2009 23:40:18 -0000 1.28 +++ include/ac/signal.h 1 Mar 2010 20:13:03 -0000 @@ -72,7 +72,7 @@ LDAP_LUTIL_F(lutil_sig_t) lutil_sigactio #ifndef LDAP_SIGCHLD #ifdef SIGCHLD #define LDAP_SIGCHLD SIGCHLD -#elif SIGCLD +#elif defined(SIGCLD) #define LDAP_SIGCHLD SIGCLD #endif #endif Index: include/ac/socket.h =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/include/ac/socket.h,v retrieving revision 1.77 diff -u -p -u -p -r1.77 socket.h --- include/ac/socket.h 23 Oct 2009 10:29:50 -0000 1.77 +++ include/ac/socket.h 1 Mar 2010 20:13:03 -0000 @@ -62,7 +62,7 @@ #ifdef HAVE_WINSOCK2 #include <winsock2.h> -#elif HAVE_WINSOCK +#elif defined(HAVE_WINSOCK) #include <winsock.h> #endif @@ -110,12 +110,12 @@ LBER_F( char * ) ber_pvt_wsa_err2string LDAP_P((int)); -#elif MACOS +#elif defined(MACOS) # define tcp_close( s ) tcpclose( s ) # define tcp_read( s, buf, len ) tcpread( s, buf, len ) # define tcp_write( s, buf, len ) tcpwrite( s, buf, len ) -#elif DOS +#elif defined(DOS) # ifdef PCNFS # define tcp_close( s ) close( s ) # define tcp_read( s, buf, len ) recv( s, buf, len, 0 ) Index: libraries/liblber/nt_err.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/libraries/liblber/nt_err.c,v retrieving revision 1.18 diff -u -p -u -p -r1.18 nt_err.c --- libraries/liblber/nt_err.c 21 Jan 2009 23:40:19 -0000 1.18 +++ libraries/liblber/nt_err.c 1 Mar 2010 20:13:03 -0000 @@ -17,7 +17,7 @@ #ifdef HAVE_WINSOCK2 #include <winsock2.h> -#elif HAVE_WINSOCK +#elif defined(HAVE_WINSOCK) #include <winsock.h> #endif /* HAVE_WINSOCK(2) */ Index: libraries/libldap/init.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/libraries/libldap/init.c,v retrieving revision 1.123 diff -u -p -u -p -r1.123 init.c --- libraries/libldap/init.c 15 Nov 2009 20:48:49 -0000 1.123 +++ libraries/libldap/init.c 1 Mar 2010 20:13:03 -0000 @@ -616,7 +616,7 @@ void ldap_int_initialize( struct ldapopt return; } } /* The WinSock DLL is acceptable. Proceed. */ -#elif HAVE_WINSOCK +#elif defined(HAVE_WINSOCK) { WSADATA wsaData; if ( WSAStartup( 0x0101, &wsaData ) != 0 ) { return; Index: libraries/liblutil/detach.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/libraries/liblutil/detach.c,v retrieving revision 1.22 diff -u -p -u -p -r1.22 detach.c --- libraries/liblutil/detach.c 21 Jan 2009 23:40:23 -0000 1.22 +++ libraries/liblutil/detach.c 1 Mar 2010 20:13:03 -0000 @@ -128,7 +128,7 @@ lutil_detach( int debug, int do_close ) #ifdef HAVE_SETSID (void) setsid(); -#elif TIOCNOTTY +#elif defined(TIOCNOTTY) if ( (sd = open( "/dev/tty", O_RDWR )) != -1 ) { (void) ioctl( sd, TIOCNOTTY, NULL ); (void) close( sd ); Index: libraries/liblutil/entropy.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/libraries/liblutil/entropy.c,v retrieving revision 1.32 diff -u -p -u -p -r1.32 entropy.c --- libraries/liblutil/entropy.c 21 Jan 2009 23:40:23 -0000 1.32 +++ libraries/liblutil/entropy.c 1 Mar 2010 20:13:03 -0000 @@ -73,7 +73,7 @@ int lutil_entropy( unsigned char *buf, b close(fd); return nbytes > 0 ? -1 : 0; } -#elif PROV_RSA_FULL +#elif defined(PROV_RSA_FULL) { /* Not used since _WIN32_WINNT not set... */ HCRYPTPROV hProv = 0;

1 0

(ITS#6482) slapcat doesn't continue with -c after the first corrupted database entry
by sysadmin＠htl-leonding.ac.at 01 Mar '10

01 Mar '10

Full_Name: Himmelbauer Version: 2.4.19 OS: Gentoo Linux URL: ftp://ftp.openldap.org/incoming/himmelbauer-100301.patch Submission from: (NULL) (92.248.100.200) Was not able to retrieve database entries from a corrupted LDAP database using slapcat (openldap 2.4.19) with option -c. It aborts after the first corrupted entry with <= entry_decode: slap_str2undef_ad(object�!p): AttributeDescription contains inappropriate characters # no data for entry id=xxxxxxxx and doesn't continue with the next valid entry as I would have expected. A damaged database is not good, but as slapcat is described as the tool to recover the non-corrupted data in various forums, it would be good when it really continues on errors. Other ldap-related tools like ldapsearch ignore the damaged data, so it is really annoying, when you want to recover your data and don't even get all the readable entries. The patch corrects the handling of damaged entries by slapcat when -c is used, so that the output is continued with the next non-damaged entry. When -c is not used slapcat stops after the first corrupted entry (as expected). The patch works for me, but I know that it is not really correct, because when there would be no non-damaged entry left it would either cause a endless loop or some crashes. So a modification would be needed to stop the loop when the last database entry was processed, but I didn't know how to access that id.

1 0

slapadd problem
by tjoen 28 Feb '10

28 Feb '10

Openldap 2.4.21, patched with openldap-ntlm.diff from evolution ./configure --prefix=/usr --enable-static Db 4.7.25 ./configure --prefix=/usr --enable-compat185 --disable-static Problem with smbldap-populate: # smbldap-populate Populating LDAP directory for domain WORKGROUP (S-1-5-21-686817777-1585854605-660948164) (using builtin directory structure) adding new entry: dc=example,dc=org adding new entry: ou=People,dc=example,dc=org adding new entry: ou=Groups,dc=example,dc=org entry ou=People,dc=example,dc=org already exist. adding new entry: ou=Idmap,dc=example,dc=org ^C (hangs) test1.ldif: dn: dc=example,dc=org objectclass: dcObject objectclass: organization dc: example o: Quenya Org Network description: The Samba-3 Network LDAP Example test2.ldif: dn: sambaDomainName=WORKGROUP,dc=example,dc=org objectclass: top objectClass: sambaDomain objectClass: sambaUnixIdPool sambaDomainName: WORKGROUP sambaSID: S-1-5-21-686817777-1585854605-660948164 uidNumber: 1000 gidNumber: 1000 sambaNextRid: 1000 # /etc/rc.d/init.d/ldap stop /var/openldap-data # rm __db.00* alock *.bdb log.0000000001 # slapadd -v -l test1.ldif added: "dc=example,dc=org" (00000001) _#################### 100.00% eta none elapsed none fast! Closing DB... # slapadd -v -l test2.ldif ^C (hangs) But: /var/openldap-data # rm __db.00* alock *.bdb log.0000000001 # slapadd -v -l test2.ldif added: "sambaDomainName=WORKGROUP,dc=example,dc=org" (00000002) _#################### 100.00% eta none elapsed none fast! Closing DB...Error, entries missing! entry 1: dc=example,dc=org # slapadd -v -l test1.ldif added: "dc=example,dc=org" (00000001) _#################### 100.00% eta none elapsed none fast! Closing DB... Why first test1 then test2 doesn't work? Deadlock? slapd.conf: include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/samba.schema pidfile /var/run/slapd.pid argsfile /var/run/slapd.args loglevel 256 idletimeout 30 access to dn.base="" by self write by * auth access to attrs=userPassword by self write by * auth access to attrs=shadowLastChange by self write by * read access to * by * read by anonymous auth backend bdb database bdb cachesize 10000 suffix "dc=example,dc=org" checkpoint 1024 5 rootdn "cn=Manager,dc=example,dc=org" # /usr/sbin/slappasswd -s secret rootpw {SSHA}Z6Ton189xuv6t+OeUYxcGoLR+nZnh0Z6 directory /var/openldap-data # Indices to maintain index objectClass eq index cn pres,sub,eq index sn pres,sub,eq index uid pres,sub,eq index displayName pres,sub,eq index uidNumber eq index gidNumber eq index memberUid eq index sambaSID eq index sambaPrimaryGroupSID eq index sambaDomainName eq index default sub database monitor access to * by dn.exact="cn=Manager,dc=example,dc=org by * none

2 2

(ITS#6481) Asssert with acl-sets and referals
by raphael.ouazana＠linagora.com 25 Feb '10

25 Feb '10

Full_Name: Raphael Ouazana Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.232.151) When an URI is deferenced and when the server returns referals, an assertion is triggered in acl_set_cb_gather : assert( rs->sr_type == REP_RESULT ); It seems that sets don't handle the case where the search response is a REP_SEARCHREF. Regards, Raphaël Ouazana.

1 0

Re: ITS#6475
by manu＠netbsd.org 24 Feb '10

24 Feb '10

<masarati(a)aero.polimi.it> wrote: > It allows to configure what SASL auxprop names need the "dontUseCopy" > approach. The "cmusaslsecretOTP" is set by default, if known through the > schema. Seems nice. I hope I'll have time to test this week. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: ITS#6475
by masarati＠aero.polimi.it 24 Feb '10

24 Feb '10

A more complete fix is here: <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-02-24-dontusecopy-…> It allows to configure what SASL auxprop names need the "dontUseCopy" approach. The "cmusaslsecretOTP" is set by default, if known through the schema. Please test. p.

1 0

ITS#6480
by masarati＠aero.polimi.it 22 Feb '10

22 Feb '10

Your analysis looks correct, but the solution is not: - If the server does not recognize the control type, determines that it is not appropriate for the operation, or is otherwise unwilling to perform the operation with the control, and if the criticality field is FALSE, the server MUST ignore the control. Your fix may result in not ignoring the control. A fix is coming. Thanks, p.

1 0

(ITS#6480) Incorrect handling of noncritical LDAP_CONTROL_X_SEARCH_OPTIONS
by alastair.mccormack＠ioko.com 22 Feb '10

22 Feb '10

Full_Name: Alastair McCormack Version: 2.3.43 OS: Red Hat Enterprise Linux Server release 5.4 (Tikanga) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.98.0.249) Proprietary LDAP Client ---LDAPv3---> OpenLDAP 2.3.43 Query: ??sub(objectClass=*) Client Receives Error 53: "searchOptions contained unrecognized flag" This works fine when client is pointed at a Windows AD Domain Controller. Tracing reveals that client is setting: Control: oid=1.2.840.113556.1.4.1340 = SERVER_SEARCH_FLAG_PHANTOM_ROOT noncritical By my novice understanding of the LDAP v3 RFC, the non-critical flag should mean that the search should not fail if the Control is not supported. However, it would seem that in controls.c an unknown or unimplemented flag is causing an exception even if the Control option is non critical. I have worked around this by creating and applying the following patch (includes typo fix): --- /var/tmp/controls.c-ignore-non-crit-search-flags 2010-02-22 15:16:16.000000000 +0000 +++ openldap-2.3.43/servers/slapd/controls.c 2008-04-09 02:12:47.000000000 +0100 @@ -1425,10 +1425,10 @@ static int parseSearchOptions ( : SLAP_CONTROL_NONCRITICAL; } - if ( search_flags & ~(LDAP_SEARCH_FLAG_DOMAIN_SCOPE) ) { + if ( (search_flags & ~(LDAP_SEARCH_FLAG_DOMAIN_SCOPE)) && ctrl->ldctl_iscritical ) { /* Other search flags not recognised so far, * including: - * LDAP_SEARCH_FLAG_PHANTOM_ROOM + * LDAP_SEARCH_FLAG_PHANTOM_ROOT */ rs->sr_text = "searchOptions contained unrecognized flag"; return LDAP_UNWILLING_TO_PERFORM; I have very little C knowledge so this was more of a POC rather than a suggested solution. Many thanks for a superb application. Keep up the good work :) Alastair McCormack

1 0

Re: (ITS#6479) olcAccess filter does not work
by hellweiss＠gmx.de 21 Feb '10

21 Feb '10

That's it, Thank you. hellweiss > You need to add (before "olcAccess: {3}") something that allows search > access to any valid search base. OpenLDAP 2.4 requires search access to > the entry pseudo-attribute of the search base. > > Something like > > olcAccess: {3}to dn.subtree="dc=example,dc=com" attrs=entry by * read > > p. > -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser

1 0

ITS#6475
by masarati＠aero.polimi.it 21 Feb '10

21 Feb '10

The "easy" fix is here <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-02-21-dontusecopy-…> I haven't committed it (needs some polishing) because it touches slapo-chain(5) in a couple of places, and I'd rather be sure it does not break anything. I won't be able to work at it for a while. It needs some polishing (SASL attributes that may need dontUseCopy should be at least configurable and so). Please test.

1 0

Re: (ITS#6479) olcAccess filter does not work
by masarati＠aero.polimi.it 20 Feb '10

20 Feb '10

You need to add (before "olcAccess: {3}") something that allows search access to any valid search base. OpenLDAP 2.4 requires search access to the entry pseudo-attribute of the search base. Something like olcAccess: {3}to dn.subtree="dc=example,dc=com" attrs=entry by * read p.

1 0

Re: (ITS#6479) olcAccess filter does not work
by hellweiss＠gmx.de 20 Feb '10

20 Feb '10

> > > > olcAccess {3}to dn.subtree="dc=site" filter=(objectclass=*) > > attrs=cn,email,entry,objectClass,uid by * read > > > > works ok, changing the olcAccess filter to e.g. person > > > > olcAccess {3}to dn.subtree="dc=site" filter=(objectclass=person) > > attrs=cn,email,entry,objectClass,uid by * read > > > > gives no results > > Given that this is specifically tested by test006, and this test routinely > passes, and considering how incomplete your report is, I recommend you > provide a means to easily reproduce the issue (e.g. detailed slapd.conf, > LDIF data and details about the unsuccessful operation) in order to have > this issue report processed further. > > p. Hello p., so, if I got you right, this 'test006' states, that this must be a configuration error and I better move on to the support Mailinglist or somewhere else. If this should not be the case, here's what i've got: There's no slapd.conf, it's empty # {1}hdb, config dn: olcDatabase={1}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=site olcRootDN: cn=admin,dc=site olcRootPW: xxxxxxxxxxxxxxxx olcDbCacheSize: 10000 olcDbCheckpoint: 1024 5 olcDbIDLcacheSize: 30000 olcDbIndex: objectclass eq olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq olcDbIndex: member eq olcDbIndex: memberUid eq olcDbIndex: mail eq olcDbIndex: cn eq,sub olcDbIndex: displayName eq,sub olcDbIndex: uid eq,sub olcDbIndex: sn eq,sub olcDbIndex: givenName eq,sub olcAccess: {0}to attrs=userPassword by self write by * auth olcAccess: {1}to attrs=shadowLastChange by self write by * read olcAccess: {2}to attrs=userPKCS12 by self read by * none olcAccess: {3}to dn.subtree="dc=site" filter=(objectclass=inetOrgPerson) attrs =cn,email,entry,objectClass,uid by * read olcAccess: {4}to * by * none I've only access to the test system now, so the dc and objectclass is different. Here is the only user: # test, people, site dn: uid=test,ou=people,dc=site cn: test test gidNumber: 100 givenName: test homeDirectory: /home/test loginShell: /bin/bash objectClass: top objectClass: posixAccount objectClass: inetOrgPerson sn: test uid: test uidNumber: 1001 If I do an ldapsearch -x -b ou=people,dc=site or as test User there are no results. What I want to achieve is Anonymous and User read access only to inetOrgPerson Entries and special attributes, nothing else. No groupOfNames or device Entries in the subtree. Regards Hellweiss -- NEU: Mit GMX DSL über 1000,- ¿ sparen! http://portal.gmx.net/de/go/dsl02

1 0

Re: (ITS#6479) olcAccess filter does not work
by masarati＠aero.polimi.it 19 Feb '10

19 Feb '10

> Full_Name: hellweiss > Version: 2.4.20 > OS: openSuSE > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.135.6.106) > > > olcAccess {3}to dn.subtree="dc=site" filter=(objectclass=*) > attrs=cn,email,entry,objectClass,uid by * read > > works ok, changing the olcAccess filter to e.g. person > > olcAccess {3}to dn.subtree="dc=site" filter=(objectclass=person) > attrs=cn,email,entry,objectClass,uid by * read > > gives no results Given that this is specifically tested by test006, and this test routinely passes, and considering how incomplete your report is, I recommend you provide a means to easily reproduce the issue (e.g. detailed slapd.conf, LDIF data and details about the unsuccessful operation) in order to have this issue report processed further. p.

1 0

(ITS#6479) olcAccess filter does not work
by hellweiss＠gmx.de 19 Feb '10

19 Feb '10

Full_Name: hellweiss Version: 2.4.20 OS: openSuSE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.135.6.106) olcAccess {3}to dn.subtree="dc=site" filter=(objectclass=*) attrs=cn,email,entry,objectClass,uid by * read works ok, changing the olcAccess filter to e.g. person olcAccess {3}to dn.subtree="dc=site" filter=(objectclass=person) attrs=cn,email,entry,objectClass,uid by * read gives no results

1 0

Re: (ITS#6478) slapd crashes with segfault
by quanah＠zimbra.com 19 Feb '10

19 Feb '10

--On Friday, February 19, 2010 2:18 PM +0000 wolfgang.hummel(a)hp.com wrote: > Full_Name: Wolfgang Hummel > Version: 2.4.21 > OS: RedHat Linux 5.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (15.203.233.80) Please provide a backtrace from a version of slapd compiled with full debugging symbols (CFLAGS="-g"). Your report is too vague to provide any help. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6478) slapd crashes with segfault
by masarati＠aero.polimi.it 19 Feb '10

19 Feb '10

wolfgang.hummel(a)hp.com wrote: > Full_Name: Wolfgang Hummel > Version: 2.4.21 > OS: RedHat Linux 5.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (15.203.233.80) > > > OpenLdap crashes occasionally with a segfault error, e.g. > [root@ts2mstsv010 Ldap]# dmesg|grep slapd > slapd[8783]: segfault at 00000000000000f0 rip 0000000000459b72 rsp > 000000004286e990 error 4 > [root@ts2mstsv010 Ldap]# > After the crash, stale lock files exist, slapd_db_recover has to be run > The server is HP D380 G5 with Intel Quadcore CPU @ 2 GHz > 32 GB memory > OS is Linux Redhat 64bit 5.1 > Oracle Berkeley DB is 4.7 > The server has 5 DBs. The whole setup has a second master in identical config > with multi-master replication and 2 slaves. > The 2 main DBs have 30 Mio. entries each, the other dbs are very small. > <http://www.openldap.org/faq/data/cache/59.html> p.

1 0

(ITS#6478) slapd crashes with segfault
by wolfgang.hummel＠hp.com 19 Feb '10

19 Feb '10

Full_Name: Wolfgang Hummel Version: 2.4.21 OS: RedHat Linux 5.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (15.203.233.80) OpenLdap crashes occasionally with a segfault error, e.g. [root@ts2mstsv010 Ldap]# dmesg|grep slapd slapd[8783]: segfault at 00000000000000f0 rip 0000000000459b72 rsp 000000004286e990 error 4 [root@ts2mstsv010 Ldap]# After the crash, stale lock files exist, slapd_db_recover has to be run The server is HP D380 G5 with Intel Quadcore CPU @ 2 GHz 32 GB memory OS is Linux Redhat 64bit 5.1 Oracle Berkeley DB is 4.7 The server has 5 DBs. The whole setup has a second master in identical config with multi-master replication and 2 slaves. The 2 main DBs have 30 Mio. entries each, the other dbs are very small.

1 0

(ITS#6477) Clarify ambiguous TLS/SSL Errors in libldap/tls2c.
by bseklecki＠noc.cfi.pgh.pa.us 18 Feb '10

18 Feb '10

Full_Name: Brian A. Seklecki Version: 2.4.21 OS: FreeBSD, Linux, Plan 9, CP/M, Bubble Memory URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2607:f000:10:202:21a:a0ff:fec2:7a6c) I'll try not to be ambiguous in my bug report. We received a support request escalation regarding an ambiguous error printed by slapd(8) at init. After review, we found that SSL library calls in OpenLDAP are not properly reporting back to the user fopen() problems when TLSCert* configuration objects are unreadable by the effective POSIX user. E.g., when a private key/cert/intermediary cert chain has POSIX permissions restricting read access by "-u $USER", the following error is printed: User Steve Polyack reports a similar error here: http://www.openldap.org/lists/openldap-software/201002/msg00025.html Also Google says: Results 1-10 of about 1,730 for "main: TLS init def ctx failed: -1". Some of these result all the back to early 2003 If you look at mailing list archives, similar error reports appear thousands of times from confused users who thought they were being diligent in by setting restrictive permissions only to receive an ambiguous error that indicates nothing about excessively restrictive permissions. The problem is that this error gets printed with "-1" under too many conditions in libraries/libldap/tls2.c::ldap_pvt_tls_set_option() ...which in turn sets rc= in servers/slapd/main.c: Which prints: 2010 Feb 5 10:52:34 -08:00 host [slapd][6261] [local4] [debug] slapd[6261]: main: TLS init def ctx failed: -1 So unless you've browsed through the OpenSSL API guide, you wouldn't even know what the CTX data structure is or how it relates to this. They do a pretty shitty job of explaining it even, so why bother mentioning it? Anyway, until we can implement OpenSSL's err(3) framework, we should refer to the user to ssl.h for RC values from ldap_pvt_tls_set_option() greater than 0. For errors, greater than 1, ldap_pvt_tls_set_option() can return that in about 15 different locations. It _could also_ pass on a -1 return code from ldap_int_tls_init_ctx () at: return ldap_int_tls_init_ctx( lo, *(int *)arg ); There are no shortage of places where where -1 could be returned to user in our code, so we should make -1 return codes other negative values to nudge the user along. Additional Debug() statements would be useful, but I don't want to get greedy. ~BAS ----------------- These patches compile-test. I'll push them into our pre-production environment: $ diff -u servers/slapd/main.c-orig servers/slapd/main.c --- servers/slapd/main.c-orig 2010-02-18 16:52:37.000000000 -0500 +++ servers/slapd/main.c 2010-02-18 16:57:30.000000000 -0500 @@ -843,8 +843,16 @@ load_extop( &slap_EXOP_START_TLS, 0, starttls_extop ); } else if ( rc != LDAP_NOT_SUPPORTED ) { Debug( LDAP_DEBUG_ANY, - "main: TLS init def ctx failed: %d\n", + "main: TLS initialization of def SSL/TLS CTX object failed with err: %d\n", rc, 0, 0 ); + + if (rc < 0) { + Debug( LDAP_DEBUG_ANY, "main: something has gone terribly wrong in creation of the SSL data structure. Check filesystem permissions, ownership bits, ACLs, configuration file paths. Resort to strace(1)/ktrace(1) debugging.\n", rc, 0, 0); + } + if (rc > 0) { + Debug( LDAP_DEBUG_ANY, "main: something has gone wrong in creation of the SSL socket data structure. Please check the OpenSSL error code above against: /usr/include/openssl/ssl until we add err(3) support.\n", rc, 0, 0); + } + rc = 1; SERVICE_EXIT( ERROR_SERVICE_SPECIFIC_ERROR, 20 ); goto destroy; $ diff -u ./libraries/libldap/tls2.c-orig ./libraries/libldap/tls2.c --- ./libraries/libldap/tls2.c-orig 2010-02-18 17:14:59.000000000 -0500 +++ ./libraries/libldap/tls2.c 2010-02-18 17:16:25.000000000 -0500 @@ -704,7 +704,7 @@ switch( option ) { case LDAP_OPT_X_TLS: - if ( !arg ) return -1; + if ( !arg ) return -2; switch( *(int *) arg ) { case LDAP_OPT_X_TLS_NEVER: @@ -718,7 +718,7 @@ return 0; } - return -1; + return -3; case LDAP_OPT_X_TLS_CTX: if ( lo->ldo_tls_ctx ) @@ -757,7 +757,7 @@ lo->ldo_tls_crlfile = arg ? LDAP_STRDUP( (char *) arg ) : NULL; return 0; case LDAP_OPT_X_TLS_REQUIRE_CERT: - if ( !arg ) return -1; + if ( !arg ) return -3; switch( *(int *) arg ) { case LDAP_OPT_X_TLS_NEVER: case LDAP_OPT_X_TLS_DEMAND: @@ -767,10 +767,10 @@ lo->ldo_tls_require_cert = * (int *) arg; return 0; } - return -1; + return -4; #ifdef HAVE_OPENSSL_CRL case LDAP_OPT_X_TLS_CRLCHECK: /* OpenSSL only */ - if ( !arg ) return -1; + if ( !arg ) return -5; switch( *(int *) arg ) { case LDAP_OPT_X_TLS_CRL_NONE: case LDAP_OPT_X_TLS_CRL_PEER: @@ -778,7 +778,7 @@ lo->ldo_tls_crlcheck = * (int *) arg; return 0; } - return -1; + return -6; #endif case LDAP_OPT_X_TLS_CIPHER_SUITE: if ( lo->ldo_tls_ciphersuite ) LDAP_FREE( lo->ldo_tls_ciphersuite ); @@ -786,17 +786,17 @@ return 0; case LDAP_OPT_X_TLS_PROTOCOL_MIN: - if ( !arg ) return -1; + if ( !arg ) return -7; lo->ldo_tls_protocol_min = *(int *)arg; return 0; case LDAP_OPT_X_TLS_RANDOM_FILE: if ( ld != NULL ) - return -1; + return -8; if ( lo->ldo_tls_randfile ) LDAP_FREE (lo->ldo_tls_randfile ); lo->ldo_tls_randfile = arg ? LDAP_STRDUP( (char *) arg ) : NULL; break; case LDAP_OPT_X_TLS_NEWCTX: - if ( !arg ) return -1; + if ( !arg ) return -9; if ( lo->ldo_tls_ctx ) ldap_pvt_tls_ctx_free( lo->ldo_tls_ctx ); lo->ldo_tls_ctx = NULL;

1 0

Re: (ITS#6464) Buffer overflow
by rhafer＠suse.de 17 Feb '10

17 Feb '10

Am Mittwoch 17 Februar 2010 11:57:27 schrieb csdr(a)lthd.com: > Well .. it worked. > > Here are that stack traces if you need them anymore (I thought strace > did that) ... > > http://www.lthd.com/thread_apply_all_bt.txt > and > http://www.lthd.com/bt_full.txt > > Thank you. > > PS: I am surprised that none has encountered that bug which comes from > version 2.4.19 (AFAIK) This problem only appears when using pretty recent gcc Versions and when building with -D_FORTIFY_SOURCE=2 (At least for me). -- Ralf

1 0

(ITS#6476) Failure to delete entry with multi-master replication
by worganc＠avaya.com 17 Feb '10

17 Feb '10

Full_Name: Craig Worgan Version: 2.4.21 OS: RedHat Enterprise Linux 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.11.182.86) As per Kyle Blaney's post to the bugs mailing list (Kyle is n vacation so I am submitting this ITS on his behalf): I have encountered a situation with multi-master replication in OpenLDAP 2.4.21 where an entry deleted on one server is not deleted from its peer. I'm using Redhat Enterprise Linux 5. Here's what I did: 1. Configure Network Time Protocol with server A as the NTP master and server B as the NTP slave. 2. Configure multi-master replication between server A (server ID=1) and server B (server ID=2). 3. Start OpenLDAP service on servers A and B. 4. Add an entry to server A and ensure it's replicated to server B. 5. Add an entry to server B and ensure it's replicated to server A. 6. Stop OpenLDAP service on server A. 7. Delete an entry on server B. 8. Start OpenLDAP service on server A with sync debugging enabled (-d sync). At this point, I expected that the entry deleted from server B would be deleted from server A. Instead, the entry remained on server A and slapd displayed the following (with the entry's DN X'ed out): slapd starting do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Entry XXXXXX CSN 20100209193028.621799Z#000000#001#000000 older or equal to ctx 20100209193028.621799Z#000000#001#000000 syncprov_search_response: cookie=rid=001,sid=001,csn=20100202210831.101462Z#000000#000#000000;2010 0209193028.621799Z#000000#001#000000;20100209193118.342038Z#000000#002#0 00000 Why wouldn't the entry deleted on server B also deleted from server A? Is the failure to delete the entry related to the "entry CSN older or equal to context CSN" message? Unfortunately, I have been unable to reproduce the failure since I first saw it. All subsequent tests have shown that the entry deleted from server B is deleted from server A when the OpenLDAP service on server A is restarted. Kyle Blaney ------------------------------------------------------------------------- There is also this follow up post: I can now reliably reproduce this problem in 2.4.21 and 2.4.20 on a multi-master setup that only has five entries: 1. Stop service on server A. 2. Delete one entry on server B. 3. Start service on server A. After step 3, the entry is never deleted from server A. I have changed many aspects of configuration (replication with and without TLS, syncprov-sessionlog enabled and disabled, syncprov-checkpoint enabled and disabled, syncprov-nopresent TRUE and FALSE, syncprov-reloadhint TRUE and FALSE) and the problem still occurs. Is this problem the same one outlined in "test 058 failure" at http://www.openldap.org/lists/openldap-software/201002/msg00031.html? Kyle ---------------------------------------------------------------------- Thanks, Craig Worgan

1 0

Re: (ITS#6464) Buffer overflow
by csdr＠lthd.com 17 Feb '10

17 Feb '10

Well .. it worked. Here are that stack traces if you need them anymore (I thought strace did that) ... http://www.lthd.com/thread_apply_all_bt.txt and http://www.lthd.com/bt_full.txt Thank you. PS: I am surprised that none has encountered that bug which comes from version 2.4.19 (AFAIK)

1 0

Re: (ITS#6464) Buffer overflow
by Ralf Haferkamp 17 Feb '10

17 Feb '10

> Sorry. > I hope this helps: http://lthd.com/slapd.out Hm, that's not a stack backtrace (http://www.openldap.org/faq/index.cgi?file=59), but not apart from that, it looks like you are hit by ITS#6474. Please test again with current HEAD. Or apply the changes between 1.168 and 1.169 of servers/slapd/back-bdb/dn2id.c from CVS to your 2.4.21 release: http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/back-bdb/dn2id.c.dif… r1=1.168&r2=1.169&hideattic=1&sortbydate=0&f=h -- Ralf

1 0

(ITS#6475) SASL OTP and syncrepl
by manu＠netbsd.org 16 Feb '10

16 Feb '10

Full_Name: Emmanuel Dreyfus Version: any OS: any URL: ftp://ftp.openldap.org/incoming/ldapotp.tgz Submission from: (NULL) (213.41.141.172) When binding using SASL OTP to a replica, the bind works, but the cmusaslsecretOTP attribute is modified on the replica and fail to be propagated to the master. On the next modification, the master will overwrite the replica's updated cmusaslsecretOTP value. Here is a script that exhibit the behaviour: ftp://ftp.openldap.org/incoming/ldapotp.tgz That require SASL enabled OpenLDAP, with the OTP plugin installed. The PATH in run.sh must probably be adjusted.

1 0

(ITS#6474) test004 (hdb) crashes when slapd is compiled with -D_FORTIFY_SOURCE=2
by ralf＠OpenLDAP.org 15 Feb '10

15 Feb '10

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: linux (gcc 4.5) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.207.32) Submitted by: ralf gcc 4.5 will do some stricter checks for buffer overflows when compiling with -D_FORTIFY_SOURCE=2. Current HEAD aborts in test004-modify with: *** buffer overflow detected ***: /usr/src/packages/BUILD/openldap-2.4.21/servers/slapd/.libs/slapd terminated ======= Backtrace: ========= #0 0x00007f207dc6b9c5 in raise () from /lib64/libc.so.6 #1 0x00007f207dc6ced6 in abort () from /lib64/libc.so.6 #2 0x00007f207dca6ba9 in __libc_message () from /lib64/libc.so.6 #3 0x00007f207dd20537 in __fortify_fail () from /lib64/libc.so.6 #4 0x00007f207dd1e2e0 in __chk_fail () from /lib64/libc.so.6 #5 0x00007f207fa89769 in strcpy () at dn2id.c:679 There is no real buffer overflow here AFAICS but the real problem is, that the destination of the strcpy() is defined as char[1] in this case (it's the nrdn member of a struct diskNode). The additional runtime check when compiling with -D_FORTIFY_SOURCE=2 sees that the destination data will not fit in there and aborts. The easiest fix here (apart from not building with -D_FORTIFY_SOURCE=2) is to use memcpy instead of strcpy here. I'll submit that later today.

1 0

Re: (ITS#6322) slapd suddenly stops working, and starts using 100% CPU
by helge＠monsternett.no 15 Feb '10

15 Feb '10

Hello again. We randomly tried to switch to LDAP without SSL last Friday (we used ldaps://..:636/ before), and the server hasn't crashed since! This is a good enough workaround for us, but I hope this information can help with fixing this bug, or help others with the same problem. On Wed, Dec 30, 2009 at 02:08:00PM +0100, Helge Milde wrote: >On Wed, Dec 30, 2009 at 09:04:12AM +0100, Helge Milde wrote: >>I just enabled trace loglevel, perhaps that might give us a clue on what's going on. > >Slapd just stopped working again. Here's the (annotated) log for viewing and/or downloading: >http://www.pastie.org/761198.txt > >Does this give you any clues? > >Tell me if I can do anything else to help. > >-- >Helge Milde, 69701808 >www.monsternett.no -- Helge Milde, 69701808 www.monsternett.no

1 0

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by j＠gropefruit.com 14 Feb '10

14 Feb '10

If nothing else, if this is in fact some strange 'elusive' bug, someone = else experiencing it may find this thread useful or enlightening in some = way (or perhaps it may help them further identify the particulars of = this intermittent phenomenon). I too must avoid spending further time = on this issue, as my team considers it suitably fixed; thus not = requiring further invested resources on my part. Thanks for your time on this issue, I must move on now. J=

1 0

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by masarati＠aero.polimi.it 14 Feb '10

14 Feb '10

> Interesting. I can't seem to imagine why this behaved the way it did = > (looking over my config again) I am just happy that moving it fixed = > the issue. Well, unless you can come up with a configuration AND a test case that is fully reproducible, I'd rather avoid spending further time on this issue. If the problem is related to intermixing configuration statements, then it is a bug, but it might only surface when something really odd happens (like one module mucking with some pointer somewhere and not restoring things as they should be). Then the only thing we can do is exactly track what caused this. However, in your case, you're not actually intermixing statements, but rather sort overlays differently: all dynlist related statements exactly follow the "overlay dynlist" statement, but different overlays are ordered differently. This calls for unexpected interaction between overlays stack execution that results in the odd behavior you observed. This should be a bug as well, unless there is a good reason for having different behavior when overlays are stacked differently (e.g. an overlay legally mucks with data that is later handled by another). Again, unless you can present a clearly reproducible case, it's quite hard to track, and likely impossible if it's data dependent. So I'm happy you solved your specific issue by rearranging the order of the overlays. p.

1 0

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by j＠gropefruit.com 14 Feb '10

14 Feb '10

Interesting. I can't seem to imagine why this behaved the way it did = (looking over my config again) I am just happy that moving it fixed = the issue. On Feb 14, 2010, at 00:55 , masarati(a)aero.polimi.it wrote: >> First of all, I am paraphrasing. No one is hiding anything from you = =3D >> Pierre. You need only ask.=3D20 >>=20 >>> It is supposed to be a bug. It's also the reason I asked from the >>> beginning to see the real configuration, real data and real = operation >>> causing the issue. If you keep hiding essential details, and only =3D= >> provide >>> bits of information each time, it'll take ages to just discover = where =3D >> the >>> issue is. >>=20 >>=20 >>> So now the only way to keep this ITS open is to see your ENTIRE =3D >> slapd.conf >>> (except passwords, of course). An even better alternative would be = to >>> receive a sanitized slapd.conf, a LDIF and a search operation based = on >>> ldapsearch that clearly illustrates the issue, like what I posted a = =3D >> couple >>> of postings ago. >>=20 >> Here, the entire sanitized config. I left out the ACL file (the = include =3D >> statement at the very end), but the behavior in question was = happening =3D >> to the rootdn user as well, meaning ACLs weren't the culprit. I also = =3D >> removed 14 of 15 of the syncrepl stanzas for brevity, as they were = all =3D >> the same aside from hostname/IP. >>=20 >> NOTE the sections labeled WORKS HERE, and BROKEN HERE, which denote = the =3D >> original (dysfunctional) position vs the current (functional) = position. >=20 > I can't see any difference in behavior with the configuration in > <ftp://ftp.openldap.org/incoming/slapd-its6471-1.conf>, the data and = the > ldapsearch command described in my previous posting (the only = difference > is that now, after "./run -b hdb test003" you need to manually create > directory "testrun/db.2.a" for the log database, and bind as the = rootdn to > perform the search). I tried both HEAD and current re24 code, which > should not differ much from 2.4.21. The only modifications to > configuration are related to: statically built backends/overlays, no = ACLs, > no TLS. Also, valgrind does not show anything strange (like dangling > pointers or so) which could be symptoms of doing nasty things with = memory > that make my setup work "by chance". >=20 > p. >=20

1 0

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by masarati＠aero.polimi.it 14 Feb '10

14 Feb '10

> First of all, I am paraphrasing. No one is hiding anything from you = > Pierre. You need only ask.=20 > >> It is supposed to be a bug. It's also the reason I asked from the >> beginning to see the real configuration, real data and real operation >> causing the issue. If you keep hiding essential details, and only = > provide >> bits of information each time, it'll take ages to just discover where = > the >> issue is. > > >> So now the only way to keep this ITS open is to see your ENTIRE = > slapd.conf >> (except passwords, of course). An even better alternative would be to >> receive a sanitized slapd.conf, a LDIF and a search operation based on >> ldapsearch that clearly illustrates the issue, like what I posted a = > couple >> of postings ago. > > Here, the entire sanitized config. I left out the ACL file (the include = > statement at the very end), but the behavior in question was happening = > to the rootdn user as well, meaning ACLs weren't the culprit. I also = > removed 14 of 15 of the syncrepl stanzas for brevity, as they were all = > the same aside from hostname/IP. > > NOTE the sections labeled WORKS HERE, and BROKEN HERE, which denote the = > original (dysfunctional) position vs the current (functional) position. I can't see any difference in behavior with the configuration in <ftp://ftp.openldap.org/incoming/slapd-its6471-1.conf>, the data and the ldapsearch command described in my previous posting (the only difference is that now, after "./run -b hdb test003" you need to manually create directory "testrun/db.2.a" for the log database, and bind as the rootdn to perform the search). I tried both HEAD and current re24 code, which should not differ much from 2.4.21. The only modifications to configuration are related to: statically built backends/overlays, no ACLs, no TLS. Also, valgrind does not show anything strange (like dangling pointers or so) which could be symptoms of doing nasty things with memory that make my setup work "by chance". p.

1 0

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by j＠gropefruit.com 13 Feb '10

13 Feb '10

First of all, I am paraphrasing. No one is hiding anything from you = Pierre. You need only ask.=20 > It is supposed to be a bug. It's also the reason I asked from the > beginning to see the real configuration, real data and real operation > causing the issue. If you keep hiding essential details, and only = provide > bits of information each time, it'll take ages to just discover where = the > issue is. > So now the only way to keep this ITS open is to see your ENTIRE = slapd.conf > (except passwords, of course). An even better alternative would be to > receive a sanitized slapd.conf, a LDIF and a search operation based on > ldapsearch that clearly illustrates the issue, like what I posted a = couple > of postings ago. Here, the entire sanitized config. I left out the ACL file (the include = statement at the very end), but the behavior in question was happening = to the rootdn user as well, meaning ACLs weren't the culprit. I also = removed 14 of 15 of the syncrepl stanzas for brevity, as they were all = the same aside from hostname/IP. NOTE the sections labeled WORKS HERE, and BROKEN HERE, which denote the = original (dysfunctional) position vs the current (functional) position. ###### include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/misc.schema include /etc/ldap/schema/openldap.schema include /etc/ldap/schema/duaconf.schema include /etc/ldap/schema/dyngroup.schema include /etc/ldap/schema/ppolicy.schema include /etc/ldap/schema/sudo.schema include /etc/ldap/schema/dhcp.schema include /etc/ldap/schema/samba.schema include /usr/share/doc/libpam-ldap/ldapns.schema include /etc/ldap/schema/hdb.schema include /etc/ldap/schema/uber.schema include /etc/ldap/schema/nisdomainobject.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args tool-threads 4 loglevel stats stats2 sync ## Modules/Overlays modulepath /usr/lib/ldap moduleload back_hdb moduleload back_monitor.la moduleload syncprov moduleload accesslog moduleload dynlist.la serverID 100 ldap://10.94.100.100:3890/ TLSCertificateFile /etc/ldap/ssl/wildcard.example.com.crt TLSCertificateKeyFile /etc/ldap/ssl/wildcard.example.com.key TLSCACertificateFile /etc/ssl/certs/ca-example.cert TLSVerifyClient never ## Limits, Mandates & Allowances disallow bind_anon sizelimit unlimited timelimit unlimited security tls=3D0 access to dn.subtree=3D"cn=3DSubschema" by users read access to dn.base=3D"" by users read defaultSearchBase dc=3Dexample,dc=3Dcom sasl-realm EXAMPLE.COM sasl-host ds.example.com authz-regexp "uid=3D$.*$,cn=3DEXAMPLE.COM,cn=3Dgssapi,cn=3Dauth" "uid=3D$1,cn=3Dplain,cn=3Dauth,dc=3Dexample,dc=3Dcom" backend hdb ########### Monitoring Database - For slapd/hdb performance data database monitor rootdn uid=3Dmonitor,cn=3Dmonitor rootpw {SSHA}.... access to dn.subtree=3D"cn=3Dmonitor" by = group/groupOfUniqueNames/uniqueMember=3D"cn=3Dldapadmin,cn=3Dldap,cn=3Dgro= ups,dc=3Dexample,dc=3Dcom" read ########### Example Log database hdb suffix cn=3Dexamplelog rootdn "uid=3Dlog,cn=3Dexamplelog" rootpw {SSHA}.... directory /var/lib/ldap/examplelog index reqStart,objectClass,entryCSN,reqResult eq dbconfig set_cachesize 0 4097152 0 dbconfig set_lg_regionmax 1048576 dbconfig set_lg_max 1048576 dbconfig set_lg_dir /var/lib/ldap/examplelog dbconfig set_tmp_dir /tmp overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE access to dn.subtree=3D"cn=3Dexamplelog" by = group/groupOfUniqueNames/uniqueMember=3D"cn=3Dldapadmin,cn=3Dldap,cn=3Dgro= ups,dc=3Dexample,dc=3Dcom" read ########### Example.Com database hdb idlcachesize 4000 suffix "dc=3Dexample,dc=3Dcom" checksum checkpoint 10 1 cachefree 20 rootdn "uid=3Drootdn,cn=3Dplain,cn=3Dauth,dc=3Dexample,dc= =3Dcom" rootpw {SSHA}.... monitoring on lastmod on directory "/var/lib/ldap/example" dncachesize 1000 dbconfig set_cachesize 1 0 2 dbconfig set_lg_max 10485760 dbconfig set_lg_regionmax 40485760 dbconfig set_flags db_log_autoremove dbconfig set_lg_bsize 20971520 dbconfig set_lk_max_objects 5500 dbconfig set_lk_max_locks 5500 dbconfig set_lk_max_lockers 5500 index objectClass eq =20 index entryCSN,entryUUID eq =20 index cn,uid,memberUid eq index uidNumber,gidNumber eq ############### ### WORKS HERE overlay dynlist dynlist-attrset groupOfURLs memberURL memberUid dynlist-attrset posixGroup memberURL memberUid:uid ## There were 15 of these, removed 14 for brevity. syncrepl rid=3D001 provider=3Dldap://10.94.100.100:3890/ starttls=3Dyes bindmethod=3Dsimple binddn=3D"uid=3Dsyncrepl,cn=3Dplain,cn=3Dauth,dc=3Dexample,dc=3Dcom" credentials=3Dpassword scope=3Dsub filter=3D"(objectClass=3D*)" schemachecking=3Doff searchbase=3D"dc=3Dexample,dc=3Dcom" attrs=3D"*,+" retry=3D"12 +" sizelimit=3Dunlimited timeout=3D20 type=3DrefreshAndPersist mirrormode true overlay syncprov syncprov-sessionlog 10 syncprov-checkpoint 1 5 overlay accesslog logdb cn=3Dexamplelog logops writes logold (objectclass=3D*) logpurge 7+00:00 2+00:00 logsuccess TRUE ################## ### IS BROKEN HERE overlay dynlist dynlist-attrset groupOfURLs memberURL memberUid dynlist-attrset posixGroup memberURL memberUid:uid include /etc/ldap/acls

1 0

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by masarati＠aero.polimi.it 13 Feb '10

13 Feb '10

> Actually, maybe I wasn't totally wrong. There MAY be a bug at work, = > just not the one I initially thought .... > > 1.) Implemented your exact working example on my dev server. Worked. > 2.) Implemented same example on my QA server. Worked. > 3.) Implemented on a production server. Failed. > > I then realized the dynlist-attrset was listed as follows: > > syncrepl params > accesslog params > dynlist-attrset params > > I then moved the slapd.conf dynlist configuration lines ABOVE syncrepl = > lines (below my indexes for this DB). > > Example then worked in production. > > Is THAT a bug? That its behavior changes depending on where it is placed = > inside of a given 'database' section? > > Thanks, sorry to keep bugging you with this .... GUESSING what you meant above is something like this (as you keep writing things like "accesslog parameters" instead of the real thing) <slapd.conf excerpt> database bdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw secret #null#bind on directory testrun/db.1.a index objectClass eq index cn,sn,uid pres,eq,sub overlay dynlist dynlist-attrset groupOfURLs memberURL memberUid overlay syncprov overlay accesslog logdb cn=log logops writes reads logold (objectclass=person) dynlist-attrset posixGroup memberURL memberUid:uid </slapd.conf excerpt> or any permutation of the dynlist-attrset statement, like both before overlay syncprov, or both at the end, or anywhere between "overlay syncrepl" and the last "log*" statement, I get the expected result. So now the only way to keep this ITS open is to see your ENTIRE slapd.conf (except passwords, of course). An even better alternative would be to receive a sanitized slapd.conf, a LDIF and a search operation based on ldapsearch that clearly illustrates the issue, like what I posted a couple of postings ago. p.

1 0

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by masarati＠aero.polimi.it 13 Feb '10

13 Feb '10

> Actually, maybe I wasn't totally wrong. There MAY be a bug at work, = > just not the one I initially thought .... > > 1.) Implemented your exact working example on my dev server. Worked. > 2.) Implemented same example on my QA server. Worked. > 3.) Implemented on a production server. Failed. > > I then realized the dynlist-attrset was listed as follows: > > syncrepl params > accesslog params > dynlist-attrset params > > I then moved the slapd.conf dynlist configuration lines ABOVE syncrepl = > lines (below my indexes for this DB). > > Example then worked in production. > > Is THAT a bug? That its behavior changes depending on where it is placed = > inside of a given 'database' section? It is supposed to be a bug. It's also the reason I asked from the beginning to see the real configuration, real data and real operation causing the issue. If you keep hiding essential details, and only provide bits of information each time, it'll take ages to just discover where the issue is. p.

1 0

Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by alinachegalati＠yahoo.com 13 Feb '10

13 Feb '10

--0-1691785669-1266069835=:3216 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Serghei, =A0 =A0=A0 I am using OpenLdap 2.4.19. By examining the change log i don't see = any behaviour=A0 change for ldap_search functions against 2.4.16. =A0 =A0 My application is already multithreaded. Different search requests come= in the same time=A0and multiple threads are usedfor this. There is an ldap= connection pool in place, a thread will pick up a free connection, will us= e it for search and return it back to the pool. =A0 =A0 I used the sync api because I looked over the OpenLdap source code and = the sync api is based on the async one.=A0While waiting for a meesage, the = async api will examine the abandoned results and destroy them. However it l= ooks like this behaviour doesn't work very well.=A0 =A0 =A0 You mentioned "But you can filter itby using ldap_msgtype() and killing= the results for searches only." Can you provide a piece of code for that? =A0 Thanks, Alin =A0 --- On Sat, 2/13/10, linamat(a)telco.md <linamat(a)telco.md> wrote: From: linamat(a)telco.md <linamat(a)telco.md> Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT To: alinachegalati(a)yahoo.com Date: Saturday, February 13, 2010, 4:44 AM > > Sorry, it is my fault here. I missed the trailling "s"... > > I am using the OpenLDAP api only for searching for ldap entries on a different LDAP serve (I am not aware of its type).=A0 So the only libraries linked to my app are libldap_r.so and liblber.so. > And what version of library? I am using 2.4.16. > I don' have access to the source code now but I'll post a section of it soon. > You are welcome;) > The idea of using ldap_result with LDAP_RES_ANY is interesting. Do you >know what is the difference between LDAP_RES_ANY and LDAP_RES_UNSOLICITED? The answer is on http://www.openldap.org/lists/openldap-technical/200912/msg00007.html As I know LDAP_RES_ANY includes search results too. But you can filter it by using ldap_msgtype() and killing the results for searches only. >I'm thinking to create a separate daemon thread that takes > ldap_connections from the pool and makes this call. My main concern is not >to clash with the existing results. > Good aproach. But if you should switch to asyncronous version of calls, you could beep the horn during periods of waiting for results withing one thread. > I'll try this solution and let you know how it worked. > > Regards, > Alin > > > --- On Sat, 2/13/10, linamat(a)telco.md <linamat(a)telco.md> wrote: > > > From: linamat(a)telco.md <linamat(a)telco.md> > Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT > To: alinachegalati(a)yahoo.com > Date: Saturday, February 13, 2010, 12:52 AM > > >> >>=A0 =A0 =A0 For the first point, the function ldap_msgfree=A0 will check = for > NULL, > so if the check is missing, no error occurs. >> > > I believe the pointer should be checked for NULL just to be safe in cases when implementation suddenly changes. > >>=A0 =A0=A0=A0I am using the ldap_search_ext_s function (the synchronous o= ne) so > the >second and third point doesn't apply as i don't have access to the msgid. >If the memory leak is high maybe will switch to the > async queries. >> Regards, >> Alin > > You wrote "We have a memory leak LDAP_TIMEOUT is encountered on > ldap_search_ext_invocation". It not clear if sync or async primitive is used. If ldap_search_ext_s is used then general timeout set per > LDAPConnection is aplied. May be ldap_search_ext_st is better for use. > > As to point 3 it can be applied in your case for checking and destroying pending or timed out operations. > > I am currently using openldap in different applications on Solaris x86/x64/sparc=A0=A0=A0both 32-bit and 64 without any troubles. Also we need= to mention that you can try libldap for version 2.4.16 as it seems to be rock stable and free of this issues. Also if you are using dbd backend, dbd must be 4.7.25 + 4 patches recommended by Oracle. > > You could post the code block for verifying. > > With respect, Serghei. > >> >> >> >> >> --- On Fri, 2/12/10, linamat(a)telco.md <linamat(a)telco.md> wrote: >> >> >> From: linamat(a)telco.md <linamat(a)telco.md> >> Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT >> To: openldap-its(a)OpenLDAP.org >> Cc: alinachegalati(a)yahoo.com >> Date: Friday, February 12, 2010, 1:34 PM >> >> >> Buna ziua, domnule. >> >> 1. The pointer must be checked before operation, e.g. >> if (res !=3D NULL) { >>=A0 =A0=A0=A0ldap_msgfree (res); >>=A0 =A0=A0=A0res =3D NULL; >> } >> >> 2. Also while processing the ext query, you should call the functions in > the following manner: >> 2.1 ldap_search_ext() which has pointer to msgid >> 2.2 ldap_result() which gives the LDAPMessage structure for the msgid > 2.3 if ok - ldap_parse_result() >> 2.4 on any stage if something is not good and you have the msgid filled > with value (integer, typicaly more then 1) you should call >> ldap_abandon_ext() for that msgid >> 2.5 Finish with ldap_msgfree() >> >> 3. Periodically between the asynchronous searches (after 100 for > example)you should call ldap_result() with short timer and LDAP_RES_ANY argue for clearing stalled or nonfreed calls. The obtained LDAPMessage can be freed with ldap_msgfree(). Of course, you can count the asynch calls which hadn't been completed or were timed out and you can make the corresponding cycle for checking all iterations. >> >> Please try and let me know. >> >> With respect, Serghei. >> >> >> >> >> > > > > > > =0A=0A=0A --0-1691785669-1266069835=:3216 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"= top" style=3D"font: inherit;"><DIV><BR>Hi Serghei,</DIV> <DIV> </DIV> <DIV>   I am using OpenLdap 2.4.19. By examining the change log i= don't see any behaviour  change for ldap_search functions against 2.4= .16.</DIV> <DIV> </DIV> <DIV>  My application is already multithreaded. Different search reque= sts come in the same time and multiple threads are usedfor this. There= is an ldap connection pool in place, a thread will pick up a free connecti= on, will use it for search and return it back to the pool.</DIV> <DIV> </DIV> <DIV>  I used the sync api because I looked over the OpenLdap source c= ode and the sync api is based on the async one. While waiting for a me= esage, the async api will examine the abandoned results and destroy them. H= owever it looks like this behaviour doesn't work very well. </DIV> <DIV> </DIV> <DIV>  You mentioned "But you can filter itby using ldap_msgtype() and= killing the results for searches only." Can you provide a piece of code fo= r that?</DIV> <DIV> </DIV> <DIV>Thanks,</DIV> <DIV>Alin<BR></DIV> <DIV> </DIV> <DIV>--- On <B>Sat, 2/13/10, linamat(a)telco.md <I><linamat(a)telco.md></= I></B> wrote:<BR></DIV> <BLOCKQUOTE style=3D"BORDER-LEFT: rgb(16,16,255) 2px solid; PADDING-LEFT: 5= px; MARGIN-LEFT: 5px"><BR>From: linamat(a)telco.md <linamat(a)telco.md><B= R>Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT<BR>To: alina= chegalati(a)yahoo.com<BR>Date: Saturday, February 13, 2010, 4:44 AM<BR><BR> <DIV class=3DplainMail>><BR>> Sorry, it is my fault here. I missed th= e trailling "s"...<BR>><BR>> I am using the OpenLDAP api only for sea= rching for ldap entries on a<BR>different LDAP serve (I am not aware of its= type).  So the only<BR>libraries linked to my app are libldap_r.so an= d liblber.so.<BR>><BR><BR>And what version of library?<BR>I am using 2.4= .16.<BR><BR>> I don' have access to the source code now but I'll post a = section of it<BR>soon.<BR>><BR><BR>You are welcome;)<BR><BR>> The ide= a of using ldap_result with LDAP_RES_ANY is interesting. Do you<BR>>know= what is the difference between LDAP_RES_ANY and<BR>LDAP_RES_UNSOLICITED?<B= R><BR>The answer is on<BR><A href=3D"http://www.openldap.org/lists/openldap= -technical/200912/msg00007.html" target=3D_blank>http://www.openldap.org/li= sts/openldap-technical/200912/msg00007.html</A><BR><BR>As I know LDAP_RES_A= NY includes search results too. But you can filter it<BR>by using ldap_msgtype() and killing the results for searches only.<BR><BR>>I'm t= hinking to create a separate daemon thread that takes<BR>> ldap_connecti= ons from the pool and makes this call. My main concern is<BR>not >to cla= sh with the existing results.<BR>><BR><BR>Good aproach. But if you shoul= d switch to asyncronous version of calls,<BR>you could beep the horn during= periods of waiting for results withing one<BR>thread.<BR><BR>> I'll try= this solution and let you know how it worked.<BR>><BR>> Regards,<BR>= > Alin<BR>><BR>><BR>> --- On Sat, 2/13/10, <A href=3D"http://us= .mc507.mail.yahoo.com/mc/compose?to=3Dlinamat(a)telco.md" ymailto=3D"mailto:l= inamat(a)telco.md">linamat(a)telco.md</A> <<A href=3D"http://us.mc507.mail.y= ahoo.com/mc/compose?to=3Dlinamat@telco.md" ymailto=3D"mailto:linamat@telco.= md">linamat(a)telco.md</A>> wrote:<BR>><BR>><BR>> From: <A href= =3D"http://us.mc507.mail.yahoo.com/mc/compose?to=3Dlinamat@telco.md" ymailto=3D"mailto:linamat@telco.md">linamat(a)telco.md</A> <<A href=3D"ht= tp://us.mc507.mail.yahoo.com/mc/compose?to=3Dlinamat@telco.md" ymailto=3D"m= ailto:linamat@telco.md">linamat(a)telco.md</A>><BR>> Subject: Re: (ITS#= 6453) OpenLDAP memory leak on LDAP_TIMEOUT<BR>> To: <A href=3D"http://us= .mc507.mail.yahoo.com/mc/compose?to=3Dalinachegalati(a)yahoo.com" ymailto=3D"= mailto:alinachegalati@yahoo.com">alinachegalati(a)yahoo.com</A><BR>> Date:= Saturday, February 13, 2010, 12:52 AM<BR>><BR>><BR>>><BR>>&= gt;      For the first point, the function ldap_msgfree&nbsp= ; will check for<BR>> NULL, > so if the check is missing, no error oc= curs.<BR>>><BR>><BR>> I believe the pointer should be checked f= or NULL just to be safe in<BR>cases when implementation suddenly changes.<B= R>><BR>>>     I am using the ldap_search_ext_s= function (the synchronous one) so<BR>> the >second and third point d= oesn't apply as i don't have access to the<BR>msgid. >If the memory leak is hi= gh maybe will switch to the<BR>> async queries.<BR>>> Regards,<BR>= >> Alin<BR>><BR>> You wrote "We have a memory leak LDAP_TIMEOUT= is encountered on<BR>> ldap_search_ext_invocation". It not clear if syn= c or async primitive is<BR>used. If ldap_search_ext_s is used then general = timeout set per<BR>> LDAPConnection is aplied. May be ldap_search_ext_st= is better for use.<BR>><BR>> As to point 3 it can be applied in your= case for checking and destroying<BR>pending or timed out operations.<BR>&g= t;<BR>> I am currently using openldap in different applications on Solar= is<BR>x86/x64/sparc   both 32-bit and 64 without any trouble= s. Also we need to<BR>mention that you can try libldap for version 2.4.16 a= s it seems to be<BR>rock stable and free of this issues. Also if you are us= ing dbd backend,<BR>dbd must be 4.7.25 + 4 patches recommended by Oracle.<BR>><BR>> You could post the code block for verifying.<BR>&g= t;<BR>> With respect, Serghei.<BR>><BR>>><BR>>><BR>>&g= t;<BR>>><BR>>> --- On Fri, 2/12/10, <A href=3D"http://us.mc507.= mail.yahoo.com/mc/compose?to=3Dlinamat@telco.md" ymailto=3D"mailto:linamat@= telco.md">linamat(a)telco.md</A> <<A href=3D"http://us.mc507.mail.yahoo.co= m/mc/compose?to=3Dlinamat(a)telco.md" ymailto=3D"mailto:linamat@telco.md">lin= amat(a)telco.md</A>> wrote:<BR>>><BR>>><BR>>> From: <A h= ref=3D"http://us.mc507.mail.yahoo.com/mc/compose?to=3Dlinamat@telco.md" yma= ilto=3D"mailto:linamat@telco.md">linamat(a)telco.md</A> <<A href=3D"http:/= /us.mc507.mail.yahoo.com/mc/compose?to=3Dlinamat(a)telco.md" ymailto=3D"mailt= o:linamat@telco.md">linamat(a)telco.md</A>><BR>>> Subject: Re: (ITS#= 6453) OpenLDAP memory leak on LDAP_TIMEOUT<BR>>> To: <A href=3D"http:= //us.mc507.mail.yahoo.com/mc/compose?to=3Dopenldap-its(a)OpenLDAP.org" ymailto=3D"mailto:openldap-its@OpenLDAP.org">openldap-its(a)OpenLDAP.org</A>= <BR>>> Cc: <A href=3D"http://us.mc507.mail.yahoo.com/mc/compose?to=3D= alinachegalati(a)yahoo.com" ymailto=3D"mailto:alinachegalati@yahoo.com">alina= chegalati(a)yahoo.com</A><BR>>> Date: Friday, February 12, 2010, 1:34 P= M<BR>>><BR>>><BR>>> Buna ziua, domnule.<BR>>><BR>&g= t;> 1. The pointer must be checked before operation, e.g.<BR>>> if= (res !=3D NULL) {<BR>>>     ldap_msgfree (res);<= BR>>>     res =3D NULL;<BR>>> }<BR>>>= <BR>>> 2. Also while processing the ext query, you should call the fu= nctions in<BR>> the following manner:<BR>>> 2.1 ldap_search_ext() = which has pointer to msgid<BR>>> 2.2 ldap_result() which gives the LD= APMessage structure for the msgid<BR>> 2.3 if ok - ldap_parse_result()<B= R>>> 2.4 on any stage if something is not good and you have the msgid filled<BR>> with value (integer, typicaly more then 1) you should call<= BR>>> ldap_abandon_ext() for that msgid<BR>>> 2.5 Finish with l= dap_msgfree()<BR>>><BR>>> 3. Periodically between the asynchron= ous searches (after 100 for<BR>> example)you should call ldap_result() w= ith short timer and LDAP_RES_ANY<BR>argue for clearing stalled or nonfreed = calls. The obtained LDAPMessage<BR>can be freed with ldap_msgfree(). Of cou= rse, you can count the asynch<BR>calls which hadn't been completed or were = timed out and you can make the<BR>corresponding cycle for checking all iter= ations.<BR>>><BR>>> Please try and let me know.<BR>>><BR>= >> With respect, Serghei.<BR>>><BR>>><BR>>><BR>>= ><BR>>><BR>><BR>><BR>><BR>><BR>><BR>><BR><BR><BR= ></DIV></BLOCKQUOTE></td></tr></table><br>=0A=0A --0-1691785669-1266069835=:3216--

1 0

Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by alinachegalati＠yahoo.com 13 Feb '10

13 Feb '10

--0-1809525330-1266055620=:51355 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sorry, it is my fault here. I missed the trailling "s"...=20 =A0 I am using the OpenLDAP api only for searching for ldap entries on a differ= ent LDAP serve (I am not aware of its type).=A0 So the only libraries linke= d to my app are libldap_r.so and liblber.so. =A0 I don' have access to the source code now=A0but I'll post a section of it s= oon. =A0 The idea of using ldap_result with LDAP_RES_ANY is interesting. Do you know= what is the difference between LDAP_RES_ANY and LDAP_RES_UNSOLICITED? I'm = thinking to create a separate daemon thread that takes ldap_connections fro= m the pool and makes this call. My main concern is not to clash with the ex= isting results. =A0 I'll try this solution and let you know how it worked. =A0 Regards, Alin =A0 --- On Sat, 2/13/10, linamat(a)telco.md <linamat(a)telco.md> wrote: From: linamat(a)telco.md <linamat(a)telco.md> Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT To: alinachegalati(a)yahoo.com Date: Saturday, February 13, 2010, 12:52 AM > >=A0 =A0 =A0 For the first point, the function ldap_msgfree=A0 will check f= or NULL, > so if the check is missing, no error occurs. > I believe the pointer should be checked for NULL just to be safe in cases when implementation suddenly changes. >=A0 =A0=A0=A0I am using the ldap_search_ext_s function (the synchronous on= e) so the >second and third point doesn't apply as i don't have access to the msgid. >If the memory leak is high maybe will switch to the async queries. > Regards, > Alin You wrote "We have a memory leak LDAP_TIMEOUT is encountered on ldap_search_ext_invocation". It not clear if sync or async primitive is used. If ldap_search_ext_s is used then general timeout set per LDAPConnection is aplied. May be ldap_search_ext_st is better for use. As to point 3 it can be applied in your case for checking and destroying pending or timed out operations. I am currently using openldap in different applications on Solaris x86/x64/sparc=A0=A0=A0both 32-bit and 64 without any troubles. Also we need= to mention that you can try libldap for version 2.4.16 as it seems to be rock stable and free of this issues. Also if you are using dbd backend, dbd must be 4.7.25 + 4 patches recommended by Oracle. You could post the code block for verifying. With respect, Serghei. > > > > > --- On Fri, 2/12/10, linamat(a)telco.md <linamat(a)telco.md> wrote: > > > From: linamat(a)telco.md <linamat(a)telco.md> > Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT > To: openldap-its(a)OpenLDAP.org > Cc: alinachegalati(a)yahoo.com > Date: Friday, February 12, 2010, 1:34 PM > > > Buna ziua, domnule. > > 1. The pointer must be checked before operation, e.g. > if (res !=3D NULL) { >=A0 =A0=A0=A0ldap_msgfree (res); >=A0 =A0=A0=A0res =3D NULL; > } > > 2. Also while processing the ext query, you should call the functions in the following manner: > 2.1 ldap_search_ext() which has pointer to msgid > 2.2 ldap_result() which gives the LDAPMessage structure for the msgid 2.3 if ok - ldap_parse_result() > 2.4 on any stage if something is not good and you have the msgid filled with value (integer, typicaly more then 1) you should call > ldap_abandon_ext() for that msgid > 2.5 Finish with ldap_msgfree() > > 3. Periodically between the asynchronous searches (after 100 for example)you should call ldap_result() with short timer and LDAP_RES_ANY argue for clearing stalled or nonfreed calls. The obtained LDAPMessage can be freed with ldap_msgfree(). Of course, you can count the asynch calls which hadn't been completed or were timed out and you can make the corresponding cycle for checking all iterations. > > Please try and let me know. > > With respect, Serghei. > > > > > =0A=0A=0A --0-1809525330-1266055620=:51355 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"= top" style=3D"font: inherit;"><DIV><BR>Sorry, it is my fault here. I missed= the trailling "s"... </DIV> <DIV> </DIV> <DIV>I am using the OpenLDAP api only for searching for ldap entries on a d= ifferent LDAP serve (I am not aware of its type).  So the only librari= es linked to my app are libldap_r.so and liblber.so.</DIV> <DIV> </DIV> <DIV>I don' have access to the source code now but I'll post a section= of it soon.</DIV> <DIV> </DIV> <DIV>The idea of using ldap_result with LDAP_RES_ANY is interesting. Do you= know what is the difference between LDAP_RES_ANY and LDAP_RES_UNSOLICITED?= I'm thinking to create a separate daemon thread that takes ldap_connection= s from the pool and makes this call. My main concern is not to clash with t= he existing results.</DIV> <DIV> </DIV> <DIV>I'll try this solution and let you know how it worked.</DIV> <DIV> </DIV> <DIV>Regards,</DIV> <DIV>Alin</DIV> <DIV> </DIV> <DIV><BR>--- On <B>Sat, 2/13/10, linamat(a)telco.md <I><linamat(a)telco.md&g= t;</I></B> wrote:<BR></DIV> <BLOCKQUOTE style=3D"BORDER-LEFT: rgb(16,16,255) 2px solid; PADDING-LEFT: 5= px; MARGIN-LEFT: 5px"><BR>From: linamat(a)telco.md <linamat(a)telco.md><B= R>Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT<BR>To: alina= chegalati(a)yahoo.com<BR>Date: Saturday, February 13, 2010, 12:52 AM<BR><BR> <DIV class=3DplainMail>><BR>>      For the first point= , the function ldap_msgfree  will check for<BR>NULL, > so if the ch= eck is missing, no error occurs.<BR>><BR><BR>I believe the pointer shoul= d be checked for NULL just to be safe in cases<BR>when implementation sudde= nly changes.<BR><BR>>     I am using the ldap_search= _ext_s function (the synchronous one) so<BR>the >second and third point = doesn't apply as i don't have access to<BR>the msgid. >If the memory lea= k is high maybe will switch to the<BR>async queries.<BR>> Regards,<BR>&g= t; Alin<BR><BR>You wrote "We have a memory leak LDAP_TIMEOUT is encountered= on<BR>ldap_search_ext_invocation". It not clear if sync or async primitive= is<BR>used. If ldap_search_ext_s is used then general timeout set per<BR>L= DAPConnection is aplied. May be ldap_search_ext_st is better for use.<BR><B= R>As to point 3 it can be applied in your case for checking and destroying<BR>pending or timed out operations.<BR><BR>I am currently using= openldap in different applications on Solaris<BR>x86/x64/sparc  =  both 32-bit and 64 without any troubles. Also we need to<BR>mention t= hat you can try libldap for version 2.4.16 as it seems to be rock<BR>stable= and free of this issues. Also if you are using dbd backend, dbd<BR>must be= 4.7.25 + 4 patches recommended by Oracle.<BR><BR>You could post the code b= lock for verifying.<BR><BR>With respect, Serghei.<BR><BR>><BR>><BR>&g= t;<BR>><BR>> --- On Fri, 2/12/10, <A href=3D"http://us.mc507.mail.yah= oo.com/mc/compose?to=3Dlinamat@telco.md" ymailto=3D"mailto:linamat@telco.md= ">linamat(a)telco.md</A> <<A href=3D"http://us.mc507.mail.yahoo.com/mc/com= pose?to=3Dlinamat(a)telco.md" ymailto=3D"mailto:linamat@telco.md">linamat@tel= co.md</A>> wrote:<BR>><BR>><BR>> From: <A href=3D"http://us.mc5= 07.mail.yahoo.com/mc/compose?to=3Dlinamat@telco.md" ymailto=3D"mailto:linamat@telco.md">linamat(a)telco.md</A> <<A href=3D"ht= tp://us.mc507.mail.yahoo.com/mc/compose?to=3Dlinamat@telco.md" ymailto=3D"m= ailto:linamat@telco.md">linamat(a)telco.md</A>><BR>> Subject: Re: (ITS#= 6453) OpenLDAP memory leak on LDAP_TIMEOUT<BR>> To: <A href=3D"http://us= .mc507.mail.yahoo.com/mc/compose?to=3Dopenldap-its(a)OpenLDAP.org" ymailto=3D= "mailto:openldap-its@OpenLDAP.org">openldap-its(a)OpenLDAP.org</A><BR>> Cc= : <A href=3D"http://us.mc507.mail.yahoo.com/mc/compose?to=3Dalinachegalati@= yahoo.com" ymailto=3D"mailto:alinachegalati@yahoo.com">alinachegalati@yahoo= .com</A><BR>> Date: Friday, February 12, 2010, 1:34 PM<BR>><BR>><B= R>> Buna ziua, domnule.<BR>><BR>> 1. The pointer must be checked b= efore operation, e.g.<BR>> if (res !=3D NULL) {<BR>>   &nbs= p; ldap_msgfree (res);<BR>>     res =3D NULL;<B= R>> }<BR>><BR>> 2. Also while processing the ext query, you should= call the functions in<BR>the following manner:<BR>> 2.1 ldap_search_ext() which = has pointer to msgid<BR>> 2.2 ldap_result() which gives the LDAPMessage = structure for the msgid<BR>2.3 if ok - ldap_parse_result()<BR>> 2.4 on a= ny stage if something is not good and you have the msgid filled<BR>with val= ue (integer, typicaly more then 1) you should call<BR>> ldap_abandon_ext= () for that msgid<BR>> 2.5 Finish with ldap_msgfree()<BR>><BR>> 3.= Periodically between the asynchronous searches (after 100 for<BR>example)y= ou should call ldap_result() with short timer and LDAP_RES_ANY<BR>argue for= clearing stalled or nonfreed calls. The obtained LDAPMessage<BR>can be fre= ed with ldap_msgfree(). Of course, you can count the asynch<BR>calls which = hadn't been completed or were timed out and you can make the<BR>correspondi= ng cycle for checking all iterations.<BR>><BR>> Please try and let me= know.<BR>><BR>> With respect, Serghei.<BR>><BR>><BR>><BR>><BR>><BR><BR><BR></DIV></BLOCKQ= UOTE></td></tr></table><br>=0A=0A --0-1809525330-1266055620=:51355--

1 0

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by j＠gropefruit.com 12 Feb '10

12 Feb '10

Excellent. It's good to know I wasn't totally crazy. Likely to be fixed in 2.4.22 ? Thanks J

1 0

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by quanah＠zimbra.com 12 Feb '10

12 Feb '10

--On Saturday, February 13, 2010 2:08 AM +0000 j(a)gropefruit.com wrote: > Actually, maybe I wasn't totally wrong. There MAY be a bug at work, = > just not the one I initially thought .... > > 1.) Implemented your exact working example on my dev server. Worked. > 2.) Implemented same example on my QA server. Worked. > 3.) Implemented on a production server. Failed. > > I then realized the dynlist-attrset was listed as follows: > > syncrepl params > accesslog params > dynlist-attrset params > > I then moved the slapd.conf dynlist configuration lines ABOVE syncrepl = > lines (below my indexes for this DB). > > Example then worked in production. > > Is THAT a bug? That its behavior changes depending on where it is placed = > inside of a given 'database' section? > > Thanks, sorry to keep bugging you with this .... Yes, that would be a bug. 2.4 shouldn't be overlay order dependant. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by j＠gropefruit.com 12 Feb '10

12 Feb '10

Actually, maybe I wasn't totally wrong. There MAY be a bug at work, = just not the one I initially thought .... 1.) Implemented your exact working example on my dev server. Worked. 2.) Implemented same example on my QA server. Worked. 3.) Implemented on a production server. Failed. I then realized the dynlist-attrset was listed as follows: syncrepl params accesslog params dynlist-attrset params I then moved the slapd.conf dynlist configuration lines ABOVE syncrepl = lines (below my indexes for this DB). Example then worked in production. Is THAT a bug? That its behavior changes depending on where it is placed = inside of a given 'database' section? Thanks, sorry to keep bugging you with this .... J=

1 0

(ITS#6473) delta-syncrepl "replicates" entries with unknown schema elements
by quanah＠zimbra.com 12 Feb '10

12 Feb '10

Full_Name: Quanah Gibson-Mount Version: 2.3.43 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) Recent discrepancies on client replica systems that were 100% reproducible showed that when using delta-syncrepl, it is easy to get a master/replica out of sync in the following scenario when using slapd.conf: A) Stop the master B) update the master with a schema that adds an additional attribute C) Start the master D) Modify an existing entry on the master, setting the new attribute with a value The replica will update its database with the event, but ignoring the new attribute and the value set for it, incorrectly updating its CSN. Instead of accepting the replication event, it should stop replication until its schema is updated to match that of the master. Master log of the modification: dn: reqStart=20100213000511.000002Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20100213000511.000002Z reqEnd: 20100213000511.000003Z reqType: modify reqSession: 3 reqAuthzID: uid=zimbra,cn=admins,cn=zimbra reqDN: cn=config,cn=zimbra reqResult: 0 reqMod: zimbraMailUseDirectBuffers:= FALSE reqMod: entryCSN:= 20100213000511Z#000000#00#000000 reqMod: modifiersName:= uid=zimbra,cn=admins,cn=zimbra reqMod: modifyTimestamp:= 20100213000511Z entryUUID: 328fcc94-ac7f-102e-8753-251cf08bb530 creatorsName: cn=accesslog createTimestamp: 20100213000511Z entryCSN: 20100213000511Z#000000#00#000000 modifiersName: cn=accesslog modifyTimestamp: 20100213000511Z On the replica, we see: ber_scanf fmt ({ml{) ber: ber_dump: buf=0x9f811c0 ptr=0x9f811c3 end=0x9f81375 len=434 0000: 64 82 01 49 04 2c 72 65 71 53 74 61 72 74 3d 32 d..I.,reqStart=2 0010: 30 31 30 30 32 31 33 30 30 30 35 31 31 2e 30 30 0100213000511.00 0020: 30 30 30 32 5a 2c 63 6e 3d 61 63 63 65 73 73 6c 0002Z,cn=accessl 0030: 6f 67 30 82 01 17 30 13 04 07 72 65 71 54 79 70 og0...0...reqTyp 0040: 65 31 08 04 06 6d 6f 64 69 66 79 30 1e 04 05 72 e1...modify0...r 0050: 65 71 44 4e 31 15 04 13 63 6e 3d 63 6f 6e 66 69 eqDN1...cn=confi 0060: 67 2c 63 6e 3d 7a 69 6d 62 72 61 30 81 af 04 06 g,cn=zimbra0.... 0070: 72 65 71 4d 6f 64 31 81 a4 04 22 7a 69 6d 62 72 reqMod1..."zimbr 0080: 61 4d 61 69 6c 55 73 65 44 69 72 65 63 74 42 75 aMailUseDirectBu 0090: 66 66 65 72 73 3a 3d 20 46 41 4c 53 45 04 2b 65 ffers:= FALSE.+e 00a0: 6e 74 72 79 43 53 4e 3a 3d 20 32 30 31 30 30 32 ntryCSN:= 201002 00b0: 31 33 30 30 30 35 31 31 5a 23 30 30 30 30 30 30 13000511Z#000000 00c0: 23 30 30 23 30 30 30 30 30 30 04 2e 6d 6f 64 69 #00#000000..modi 00d0: 66 69 65 72 73 4e 61 6d 65 3a 3d 20 75 69 64 3d fiersName:= uid= 00e0: 7a 69 6d 62 72 61 2c 63 6e 3d 61 64 6d 69 6e 73 zimbra,cn=admins 00f0: 2c 63 6e 3d 7a 69 6d 62 72 61 04 21 6d 6f 64 69 ,cn=zimbra.!modi 0100: 66 79 54 69 6d 65 73 74 61 6d 70 3a 3d 20 32 30 fyTimestamp:= 20 0110: 31 30 30 32 31 33 30 30 30 35 31 31 5a 30 2e 04 100213000511Z0.. 0120: 08 65 6e 74 72 79 43 53 4e 31 22 04 20 32 30 31 .entryCSN1". 201 0130: 30 30 32 31 33 30 30 30 35 31 31 5a 23 30 30 30 00213000511Z#000 0140: 30 30 30 23 30 30 23 30 30 30 30 30 30 a0 63 30 000#00#000000.c0 0150: 61 04 18 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 34 a..1.3.6.1.4.1.4 0160: 32 30 33 2e 31 2e 39 2e 31 2e 32 04 45 30 43 0a 203.1.9.1.2.E0C. 0170: 01 01 04 10 32 8f cc 94 ac 7f 10 2e 87 53 25 1c ....2........S%. 0180: f0 8b b5 30 04 2c 63 73 6e 3d 32 30 31 30 30 32 ...0.,csn=201002 0190: 31 33 30 30 30 35 31 31 5a 23 30 30 30 30 30 30 13000511Z#000000 01a0: 23 30 30 23 30 30 30 30 30 30 2c 72 69 64 3d 31 #00#000000,rid=1 01b0: 30 30 00 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x9f811c0 ptr=0x9f811f9 end=0x9f81310 len=279 0000: 30 13 04 07 72 65 71 54 79 70 65 31 08 04 06 6d 0...reqType1...m 0010: 6f 64 69 66 79 30 1e 04 05 72 65 71 44 4e 31 15 odify0...reqDN1. 0020: 04 13 63 6e 3d 63 6f 6e 66 69 67 2c 63 6e 3d 7a ..cn=config,cn=z 0030: 69 6d 62 72 61 30 81 af 04 06 72 65 71 4d 6f 64 imbra0....reqMod 0040: 31 81 a4 04 22 7a 69 6d 62 72 61 4d 61 69 6c 55 1..."zimbraMailU 0050: 73 65 44 69 72 65 63 74 42 75 66 66 65 72 73 3a seDirectBuffers: 0060: 3d 20 46 41 4c 53 45 04 2b 65 6e 74 72 79 43 53 = FALSE.+entryCS 0070: 4e 3a 3d 20 32 30 31 30 30 32 31 33 30 30 30 35 N:= 201002130005 0080: 31 31 5a 23 30 30 30 30 30 30 23 30 30 23 30 30 11Z#000000#00#00 0090: 30 30 30 30 04 2e 6d 6f 64 69 66 69 65 72 73 4e 0000..modifiersN 00a0: 61 6d 65 3a 3d 20 75 69 64 3d 7a 69 6d 62 72 61 ame:= uid=zimbra 00b0: 2c 63 6e 3d 61 64 6d 69 6e 73 2c 63 6e 3d 7a 69 ,cn=admins,cn=zi 00c0: 6d 62 72 61 04 21 6d 6f 64 69 66 79 54 69 6d 65 mbra.!modifyTime 00d0: 73 74 61 6d 70 3a 3d 20 32 30 31 30 30 32 31 33 stamp:= 20100213 00e0: 30 30 30 35 31 31 5a 30 2e 04 08 65 6e 74 72 79 000511Z0...entry 00f0: 43 53 4e 31 22 04 20 32 30 31 30 30 32 31 33 30 CSN1". 201002130 0100: 30 30 35 31 31 5a 23 30 30 30 30 30 30 23 30 30 00511Z#000000#00 0110: 23 30 30 30 30 30 30 #000000 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x9f811c0 ptr=0x9f8120e end=0x9f81310 len=258 0000: 00 1e 04 05 72 65 71 44 4e 31 15 04 13 63 6e 3d ....reqDN1...cn= 0010: 63 6f 6e 66 69 67 2c 63 6e 3d 7a 69 6d 62 72 61 config,cn=zimbra 0020: 30 81 af 04 06 72 65 71 4d 6f 64 31 81 a4 04 22 0....reqMod1..." 0030: 7a 69 6d 62 72 61 4d 61 69 6c 55 73 65 44 69 72 zimbraMailUseDir 0040: 65 63 74 42 75 66 66 65 72 73 3a 3d 20 46 41 4c ectBuffers:= FAL 0050: 53 45 04 2b 65 6e 74 72 79 43 53 4e 3a 3d 20 32 SE.+entryCSN:= 2 0060: 30 31 30 30 32 31 33 30 30 30 35 31 31 5a 23 30 0100213000511Z#0 0070: 30 30 30 30 30 23 30 30 23 30 30 30 30 30 30 04 00000#00#000000. 0080: 2e 6d 6f 64 69 66 69 65 72 73 4e 61 6d 65 3a 3d .modifiersName:= 0090: 20 75 69 64 3d 7a 69 6d 62 72 61 2c 63 6e 3d 61 uid=zimbra,cn=a 00a0: 64 6d 69 6e 73 2c 63 6e 3d 7a 69 6d 62 72 61 04 dmins,cn=zimbra. 00b0: 21 6d 6f 64 69 66 79 54 69 6d 65 73 74 61 6d 70 !modifyTimestamp 00c0: 3a 3d 20 32 30 31 30 30 32 31 33 30 30 30 35 31 := 2010021300051 00d0: 31 5a 30 2e 04 08 65 6e 74 72 79 43 53 4e 31 22 1Z0...entryCSN1" 00e0: 04 20 32 30 31 30 30 32 31 33 30 30 30 35 31 31 . 20100213000511 00f0: 5a 23 30 30 30 30 30 30 23 30 30 23 30 30 30 30 Z#000000#00#0000 0100: 30 30 00 >>> dnPrettyNormal: <cn=config,cn=zimbra> => ldap_bv2dn(cn=config,cn=zimbra,0) <= ldap_bv2dn(cn=config,cn=zimbra)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=config,cn=zimbra)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=config,cn=zimbra)=0 <<< dnPrettyNormal: <cn=config,cn=zimbra>, <cn=config,cn=zimbra> ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x9f811c0 ptr=0x9f8122e end=0x9f81310 len=226 0000: 00 81 af 04 06 72 65 71 4d 6f 64 31 81 a4 04 22 .....reqMod1..." 0010: 7a 69 6d 62 72 61 4d 61 69 6c 55 73 65 44 69 72 zimbraMailUseDir 0020: 65 63 74 42 75 66 66 65 72 73 3a 3d 20 46 41 4c ectBuffers:= FAL 0030: 53 45 04 2b 65 6e 74 72 79 43 53 4e 3a 3d 20 32 SE.+entryCSN:= 2 0040: 30 31 30 30 32 31 33 30 30 30 35 31 31 5a 23 30 0100213000511Z#0 0050: 30 30 30 30 30 23 30 30 23 30 30 30 30 30 30 04 00000#00#000000. 0060: 2e 6d 6f 64 69 66 69 65 72 73 4e 61 6d 65 3a 3d .modifiersName:= 0070: 20 75 69 64 3d 7a 69 6d 62 72 61 2c 63 6e 3d 61 uid=zimbra,cn=a 0080: 64 6d 69 6e 73 2c 63 6e 3d 7a 69 6d 62 72 61 04 dmins,cn=zimbra. 0090: 21 6d 6f 64 69 66 79 54 69 6d 65 73 74 61 6d 70 !modifyTimestamp 00a0: 3a 3d 20 32 30 31 30 30 32 31 33 30 30 30 35 31 := 2010021300051 00b0: 31 5a 30 2e 04 08 65 6e 74 72 79 43 53 4e 31 22 1Z0...entryCSN1" 00c0: 04 20 32 30 31 30 30 32 31 33 30 30 30 35 31 31 . 20100213000511 00d0: 5a 23 30 30 30 30 30 30 23 30 30 23 30 30 30 30 Z#000000#00#0000 00e0: 30 30 00 ldap_get_attribute_ber ber_scanf fmt ({mM}) ber: ber_dump: buf=0x9f811c0 ptr=0x9f812e0 end=0x9f81310 len=48 0000: 00 2e 04 08 65 6e 74 72 79 43 53 4e 31 22 04 20 ....entryCSN1". 0010: 32 30 31 30 30 32 31 33 30 30 30 35 31 31 5a 23 20100213000511Z# 0020: 30 30 30 30 30 30 23 30 30 23 30 30 30 30 30 30 000000#00#000000 ldap_get_attribute_ber >>> dnPretty: <uid=zimbra,cn=admins,cn=zimbra> => ldap_bv2dn(uid=zimbra,cn=admins,cn=zimbra,0) <= ldap_bv2dn(uid=zimbra,cn=admins,cn=zimbra)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=zimbra,cn=admins,cn=zimbra)=0 <<< dnPretty: <uid=zimbra,cn=admins,cn=zimbra> >>> dnNormalize: <uid=zimbra,cn=admins,cn=zimbra> => ldap_bv2dn(uid=zimbra,cn=admins,cn=zimbra,0) <= ldap_bv2dn(uid=zimbra,cn=admins,cn=zimbra)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=zimbra,cn=admins,cn=zimbra)=0 <<< dnNormalize: <uid=zimbra,cn=admins,cn=zimbra> bdb_modify: cn=config,cn=zimbra bdb_dn2entry("cn=config,cn=zimbra") bdb_modify_internal: 0x0000000c: cn=config,cn=zimbra <= acl_access_allowed: granted to database root bdb_modify_internal: replace entryCSN bdb_modify_internal: replace modifiersName bdb_modify_internal: replace modifyTimestamp => key_change(DELETE,c) bdb_idl_delete_key: c <= key_change 0 => key_change(ADD,c) bdb_idl_insert_key: c <= key_change 0 => entry_encode(0x0000000c): cn=config,cn=zimbra bdb_modify: updated id=0000000c dn="cn=config,cn=zimbra" send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=0 matched="" text="" syncrepl_message_to_op: rid 100 be_modify cn=config,cn=zimbra (0) bdb_modify: bdb_dn2entry("") bdb_modify_internal: 0x00000000: <= acl_access_allowed: granted to database root bdb_modify_internal: replace contextCSN => entry_encode(0x00000000): bdb_modify: updated id=00000000 dn="" send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=0 matched="" text="" ldap_msgfree As you can see, the replica *clearly* sees the attribute in question, but fails to throw an error, and simply updates the database with all of the other changes (entryCSN, etc) then updates the contextCSN.

1 0

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by j＠gropefruit.com 12 Feb '10

12 Feb '10

> Isn't this what you expect? >=20 That is EXACTLY what I expect. But all hits either come back in POSIX = format (e.g: just the usernames alone), OR LDAP format (e.g: DNs as = members). Never BOTH (like in your example, which is what we want). So, yes, your TEST is correct. However I am seeing something very = different on my end. Clearly I am doing something wrong. Either: 1.) A syntax error somewhere in my URI syntax, or 2.) A syntax error somewhere in the dynlist overlay area in my = slapd.conf > It represents the objectClass that, when present in an entry that is = being > returned by a search, triggers the dynlist expansion. >=20 That TOO is what I interpreted from both the examples and the manpage. So you have answered my question: 1.) Is not a bug 2.) What I am trying to do is perfectly valid 3.) I am the problem - I am doing something wrong =3D) Thank you Pierangelo, as always you're extremely helpful. J > p. >=20

1 0

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by masarati＠aero.polimi.it 12 Feb '10

12 Feb '10

> Pierangelo,=20 > > Thanks for responding. Here are some hopefully helpful answers: > > We have an Openfire (Java-based XMPP server, supporting ldap user/group = > lookups) server that will, when deployed, have thousands of users. = > Openfire works quite well with openldap, however we wanted to avoid = > manually maintaining the group objects since (as I said) they would be = > highly populated. > > Openfire supports two types of groups (in their terms): posix and = > non-posix. Basically what this means is that when in posix mode, = > Openfire looks for groups (e.g: cn=3Dusers) that contain UID-like = > objects (single username strings). When in NON-POSIX mode, however, = > Openfire will look for groups that contain DN-based members. =20 > > The member Attribute names (e.g: memberUid, uniqueMember, etc) are fully = > configurable to openfire, but we had limited success when trying = > different permutations. Some attribute-mappings work, some do not. = > Eventually, we found that the following works for Openfire: > > overlay dynlist > dynlist-attrset groupOfURLs memberURL memberUid > > With this record being returned when queried: > > dn: cn=3Dusers,cn=3Dgroups,dc=3Dexample,dc=3Dcom > cn: users > memberURL: = > ldap:///cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom?uid?one?(objectClass=3D= > simpleSecurityObject) > objectClass: groupOfURLs > memberUid: > uid=3Dopenfire-admin,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom= > > memberUid: uid=3Duser1,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom > memberUid: uid=3Duser2,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom > memberUid: uid=3Duser3,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom > memberUid: uid=3Duser4,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom > memberUid: uid=3Duser5,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom > memberUid: uid=3Duser6,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom > memberUid: uid=3Duser7,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom > memberUid: uid=3Duser8,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom > memberUid: uid=3Duser9,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom > > I know this doesn't look right (obviously memberUid is not typically a = > DN-based value) BUT THIS WORKS FOR OPENFIRE (which in the end, will be = > the only client that makes use of this record). We'd prefer to use = > DN-based member groups (e.g: this would be "Non-Posix" groups to = > openfire) since this is the only method that works with Openfire. > > HOWEVER on the other side of the situation, we want to begin using = > Dynamic Posix Groups, like so: > > overlay dynlist > dynlist-attrset posixGroup memberURL memberUid:uid > > With this record being returned when queried: > > dn: cn=3Dadmins,cn=3Dposix,cn=3Dgroups,dc=3Dexample,dc=3Dcom > objectClass: posixGroup > objectClass: top > objectClass: extensibleObject > cn: systems > gidNumber: 9001 > memberURL: = > ldap:///cn=3Dplain,cn=3Dauth,dc=3Dexample,dc=3Dcom?uid?one?(objectClass=3D= > adminUser) > memberUid: admin1 > memberUid: admin2 > memberUid: admin3 > memberUid: admin4 > memberUid: admin5 > > .... Which works wonderfully! Using shell commands like 'id' , 'groups' = > will work quite nicely on the posix/shell level. > > But all goes to crap when combining the above dynlist-attrsets. As I = > said, only one seems to be evaluated. I'm afraid I don't quite understand. 1) I manually ran test003 2) I configured slapd with overlay dynlist dynlist-attrset groupOfURLs memberURL memberUid dynlist-attrset posixGroup memberURL memberUid:uid 3) I loaded the LDIF dn: ou=dynlist,dc=example,dc=com objectClass: organizationalUnit dn: cn=dl1,ou=dynlist,dc=example,dc=com objectClass: groupOfURLs memberURL: ldap:///dc=example,dc=com?uid?sub?(objectClass=person) dn: cn=dl2,ou=dynlist,dc=example,dc=com objectClass: posixGroup objectClass: extensibleObject memberURL: ldap:///dc=example,dc=com?uid?sub?(objectClass=person) gidNumber: 0 4) when I execute $ ldapsearch -x -b ou=dynlist,dc=example,dc=com I get # extended LDIF # # LDAPv3 # base <ou=dynlist,dc=example,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # dynlist, example.com dn: ou=dynlist,dc=example,dc=com objectClass: organizationalUnit ou: dynlist # dl1, dynlist, example.com dn: cn=dl1,ou=dynlist,dc=example,dc=com objectClass: groupOfURLs memberURL: ldap:///dc=example,dc=com?uid?sub?(objectClass=person) cn: dl1 memberUid: cn=Barbara Jensen,ou=Information Technology Division,ou=People, dc=example,dc=com memberUid: cn=Bjorn Jensen,ou=Information Technology Division,ou=People,dc =example,dc=com memberUid: cn=Dorothy Stevens,ou=Alumni Association,ou=People,dc=example,d c=com memberUid: cn=James A Jones 1,ou=Alumni Association,ou=People,dc=example,d c=com memberUid: cn=James A Jones 2,ou=Information Technology Division,ou=People ,dc=example,dc=com memberUid: cn=Jane Doe,ou=Alumni Association,ou=People,dc=example,dc=com memberUid: cn=Jennifer Smith,ou=Alumni Association,ou=People,dc=example,dc =com memberUid: cn=John Doe,ou=Information Technology Division,ou=People,dc=exa mple,dc=com memberUid: cn=Manager,dc=example,dc=com memberUid: cn=Mark Elliot,ou=Alumni Association,ou=People,dc=example,dc=co m memberUid: cn=Ursula Hampster,ou=Alumni Association,ou=People,dc=example,d c=com # dl2, dynlist, example.com dn: cn=dl2,ou=dynlist,dc=example,dc=com objectClass: posixGroup objectClass: extensibleObject memberURL: ldap:///dc=example,dc=com?uid?sub?(objectClass=person) gidNumber: 0 cn: dl2 memberUid: bjensen memberUid: bjorn memberUid: dots memberUid: jaj memberUid: jjones memberUid: jdoe memberUid: jen memberUid: johnd memberUid: melliot memberUid: uham # search result search: 2 result: 0 Success # numResponses: 4 # numEntries: 3 Isn't this what you expect? > I have tried incorporating the = > optional URI parameter into the dynlist-attrsets, but this totally broke = > the groups altogether (didn't expand at all). > > I guess I don't understand what role the first ObjectClass listed in the = > dynlist-attrset parameter plays - i assumed it would act appropriately = > for objects that are using the same OC that is listed in the rule. It represents the objectClass that, when present in an entry that is being returned by a search, triggers the dynlist expansion. p.

1 0

Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by alinachegalati＠yahoo.com 12 Feb '10

12 Feb '10

--0-1804724661-1266012508=:41453 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable On point to note, i have the same situation as here : http://www.openldap.o= rg/lists/openldap-technical/200912/msg00007.html --- On Fri, 2/12/10, alin vasile <alinachegalati(a)yahoo.com> wrote: From: alin vasile <alinachegalati(a)yahoo.com> Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT To: linamat(a)telco.md Cc: openldap-its(a)OpenLDAP.org Date: Friday, February 12, 2010, 1:56 PM looping openldap group --- On Fri, 2/12/10, alin vasile <alinachegalati(a)yahoo.com> wrote: From: alin vasile <alinachegalati(a)yahoo.com> Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT To: linamat(a)telco.md Date: Friday, February 12, 2010, 1:55 PM Hi Serghei, =A0 =A0=A0=A0=A0 For the first point, the function ldap_msgfree=A0 will check f= or NULL, so if the check is missing, no error occurs. =A0 =A0=A0=A0 I am using the ldap_search_ext_s function (the synchronous one) s= o the second and third point doesn't apply as i don't have access to the ms= gid. If the memory leak is high maybe will switch to the async queries. =A0 Regards, Alin =A0 =A0=A0=20 =A0=A0=A0=20 --- On Fri, 2/12/10, linamat(a)telco.md <linamat(a)telco.md> wrote: From: linamat(a)telco.md <linamat(a)telco.md> Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT To: openldap-its(a)OpenLDAP.org Cc: alinachegalati(a)yahoo.com Date: Friday, February 12, 2010, 1:34 PM Buna ziua, domnule. 1. The pointer must be checked before operation, e.g. if (res !=3D NULL) { =A0 =A0 ldap_msgfree (res); =A0 =A0 res =3D NULL; } 2. Also while processing the ext query, you should call the functions in the following manner: 2.1 ldap_search_ext() which has pointer to msgid 2.2 ldap_result() which gives the LDAPMessage structure for the msgid 2.3 if ok - ldap_parse_result() 2.4 on any stage if something is not good and you have the msgid filled with value (integer, typicaly more then 1) you should call ldap_abandon_ext() for that msgid 2.5 Finish with ldap_msgfree() 3. Periodically between the asynchronous searches (after 100 for example)you should call ldap_result() with short timer and LDAP_RES_ANY argue for clearing stalled or nonfreed calls. The obtained LDAPMessage can be freed with ldap_msgfree(). Of course, you can count the asynch calls which hadn't been completed or were timed out and you can make the corresponding cycle for checking all iterations. Please try and let me know. With respect, Serghei. =0A=0A=0A --0-1804724661-1266012508=:41453 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"= top" style=3D"font: inherit;">On point to note, i have the same situation a= s here : <A href=3D"http://www.openldap.org/lists/openldap-technical/200912= /msg00007.html">http://www.openldap.org/lists/openldap-technical/200912/msg= 00007.html</A><BR><BR>--- On <B>Fri, 2/12/10, alin vasile <I><alinachega= lati(a)yahoo.com></I></B> wrote:<BR> <BLOCKQUOTE style=3D"BORDER-LEFT: rgb(16,16,255) 2px solid; PADDING-LEFT: 5= px; MARGIN-LEFT: 5px"><BR>From: alin vasile <alinachegalati(a)yahoo.com&gt= ;<BR>Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT<BR>To: li= namat(a)telco.md<BR>Cc: openldap-its(a)OpenLDAP.org<BR>Date: Friday, February 1= 2, 2010, 1:56 PM<BR><BR> <DIV id=3Dyiv1659718545> <TABLE border=3D0 cellSpacing=3D0 cellPadding=3D0> <TBODY> <TR> <TD vAlign=3Dtop>looping openldap group<BR><BR>--- On <B>Fri, 2/12/10, alin= vasile <I><alinachegalati(a)yahoo.com></I></B> wrote:<BR> <BLOCKQUOTE style=3D"BORDER-LEFT: rgb(16,16,255) 2px solid; PADDING-LEFT: 5= px; MARGIN-LEFT: 5px"><BR>From: alin vasile <alinachegalati(a)yahoo.com&gt= ;<BR>Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT<BR>To: li= namat(a)telco.md<BR>Date: Friday, February 12, 2010, 1:55 PM<BR><BR> <DIV id=3Dyiv1668921465> <TABLE border=3D0 cellSpacing=3D0 cellPadding=3D0> <TBODY> <TR> <TD vAlign=3Dtop> <DIV>Hi Serghei,</DIV> <DIV> </DIV> <DIV>     For the first point, the function ldap_msgfre= e  will check for NULL, so if the check is missing, no error occurs.</= DIV> <DIV> </DIV> <DIV>    I am using the ldap_search_ext_s function (the sync= hronous one) so the second and third point doesn't apply as i don't have ac= cess to the msgid. If the memory leak is high maybe will switch to the asyn= c queries.</DIV> <DIV> </DIV> <DIV>Regards,</DIV> <DIV>Alin</DIV> <DIV> </DIV> <DIV>   </DIV> <DIV>    <BR><BR>--- On <B>Fri, 2/12/10, linamat(a)telco.md <I= ><linamat(a)telco.md></I></B> wrote:<BR></DIV> <BLOCKQUOTE style=3D"BORDER-LEFT: rgb(16,16,255) 2px solid; PADDING-LEFT: 5= px; MARGIN-LEFT: 5px"><BR>From: linamat(a)telco.md <linamat(a)telco.md><B= R>Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT<BR>To: openl= dap-its(a)OpenLDAP.org<BR>Cc: alinachegalati(a)yahoo.com<BR>Date: Friday, Febru= ary 12, 2010, 1:34 PM<BR><BR> <DIV class=3DplainMail>Buna ziua, domnule.<BR><BR>1. The pointer must be ch= ecked before operation, e.g.<BR>if (res !=3D NULL) {<BR>    ldap_= msgfree (res);<BR>    res =3D NULL;<BR>}<BR><BR>2. Also while pro= cessing the ext query, you should call the functions in<BR>the following ma= nner:<BR>2.1 ldap_search_ext() which has pointer to msgid<BR>2.2 ldap_resul= t() which gives the LDAPMessage structure for the msgid<BR>2.3 if ok - ldap= _parse_result()<BR>2.4 on any stage if something is not good and you have t= he msgid filled<BR>with value (integer, typicaly more then 1) you should ca= ll<BR>ldap_abandon_ext() for that msgid<BR>2.5 Finish with ldap_msgfree()<B= R><BR>3. Periodically between the asynchronous searches (after 100 for<BR>e= xample)you should call ldap_result() with short timer and LDAP_RES_ANY<BR>a= rgue for clearing stalled or nonfreed calls. The obtained LDAPMessage can<B= R>be freed with ldap_msgfree(). Of course, you can count the asynch calls<BR>which hadn't been completed or were timed out and you can make th= e<BR>corresponding cycle for checking all iterations.<BR><BR>Please try and= let me know.<BR><BR>With respect, Serghei.<BR><BR></DIV></BLOCKQUOTE></TD>= </TR></TBODY></TABLE><BR></DIV></BLOCKQUOTE></TD></TR></TBODY></TABLE><BR><= /DIV></BLOCKQUOTE></td></tr></table><br>=0A=0A=0A=0A --0-1804724661-1266012508=:41453--

1 0

Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by alinachegalati＠yahoo.com 12 Feb '10

12 Feb '10

--0-1659389023-1266011766=:33437 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable looping openldap group --- On Fri, 2/12/10, alin vasile <alinachegalati(a)yahoo.com> wrote: From: alin vasile <alinachegalati(a)yahoo.com> Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT To: linamat(a)telco.md Date: Friday, February 12, 2010, 1:55 PM Hi Serghei, =A0 =A0=A0=A0=A0 For the first point, the function ldap_msgfree=A0 will check f= or NULL, so if the check is missing, no error occurs. =A0 =A0=A0=A0 I am using the ldap_search_ext_s function (the synchronous one) s= o the second and third point doesn't apply as i don't have access to the ms= gid. If the memory leak is high maybe will switch to the async queries. =A0 Regards, Alin =A0 =A0=A0=20 =A0=A0=A0=20 --- On Fri, 2/12/10, linamat(a)telco.md <linamat(a)telco.md> wrote: From: linamat(a)telco.md <linamat(a)telco.md> Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT To: openldap-its(a)OpenLDAP.org Cc: alinachegalati(a)yahoo.com Date: Friday, February 12, 2010, 1:34 PM Buna ziua, domnule. 1. The pointer must be checked before operation, e.g. if (res !=3D NULL) { =A0 =A0 ldap_msgfree (res); =A0 =A0 res =3D NULL; } 2. Also while processing the ext query, you should call the functions in the following manner: 2.1 ldap_search_ext() which has pointer to msgid 2.2 ldap_result() which gives the LDAPMessage structure for the msgid 2.3 if ok - ldap_parse_result() 2.4 on any stage if something is not good and you have the msgid filled with value (integer, typicaly more then 1) you should call ldap_abandon_ext() for that msgid 2.5 Finish with ldap_msgfree() 3. Periodically between the asynchronous searches (after 100 for example)you should call ldap_result() with short timer and LDAP_RES_ANY argue for clearing stalled or nonfreed calls. The obtained LDAPMessage can be freed with ldap_msgfree(). Of course, you can count the asynch calls which hadn't been completed or were timed out and you can make the corresponding cycle for checking all iterations. Please try and let me know. With respect, Serghei. =0A=0A=0A --0-1659389023-1266011766=:33437 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"= top" style=3D"font: inherit;">looping openldap group<BR><BR>--- On <B>Fri, = 2/12/10, alin vasile <I><alinachegalati(a)yahoo.com></I></B> wrote:<BR> <BLOCKQUOTE style=3D"BORDER-LEFT: rgb(16,16,255) 2px solid; PADDING-LEFT: 5= px; MARGIN-LEFT: 5px"><BR>From: alin vasile <alinachegalati(a)yahoo.com&gt= ;<BR>Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT<BR>To: li= namat(a)telco.md<BR>Date: Friday, February 12, 2010, 1:55 PM<BR><BR> <DIV id=3Dyiv1668921465> <TABLE border=3D0 cellSpacing=3D0 cellPadding=3D0> <TBODY> <TR> <TD vAlign=3Dtop> <DIV>Hi Serghei,</DIV> <DIV> </DIV> <DIV>     For the first point, the function ldap_msgfre= e  will check for NULL, so if the check is missing, no error occurs.</= DIV> <DIV> </DIV> <DIV>    I am using the ldap_search_ext_s function (the sync= hronous one) so the second and third point doesn't apply as i don't have ac= cess to the msgid. If the memory leak is high maybe will switch to the asyn= c queries.</DIV> <DIV> </DIV> <DIV>Regards,</DIV> <DIV>Alin</DIV> <DIV> </DIV> <DIV>   </DIV> <DIV>    <BR><BR>--- On <B>Fri, 2/12/10, linamat(a)telco.md <I= ><linamat(a)telco.md></I></B> wrote:<BR></DIV> <BLOCKQUOTE style=3D"BORDER-LEFT: rgb(16,16,255) 2px solid; PADDING-LEFT: 5= px; MARGIN-LEFT: 5px"><BR>From: linamat(a)telco.md <linamat(a)telco.md><B= R>Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT<BR>To: openl= dap-its(a)OpenLDAP.org<BR>Cc: alinachegalati(a)yahoo.com<BR>Date: Friday, Febru= ary 12, 2010, 1:34 PM<BR><BR> <DIV class=3DplainMail>Buna ziua, domnule.<BR><BR>1. The pointer must be ch= ecked before operation, e.g.<BR>if (res !=3D NULL) {<BR>    ldap_= msgfree (res);<BR>    res =3D NULL;<BR>}<BR><BR>2. Also while pro= cessing the ext query, you should call the functions in<BR>the following ma= nner:<BR>2.1 ldap_search_ext() which has pointer to msgid<BR>2.2 ldap_resul= t() which gives the LDAPMessage structure for the msgid<BR>2.3 if ok - ldap= _parse_result()<BR>2.4 on any stage if something is not good and you have t= he msgid filled<BR>with value (integer, typicaly more then 1) you should ca= ll<BR>ldap_abandon_ext() for that msgid<BR>2.5 Finish with ldap_msgfree()<B= R><BR>3. Periodically between the asynchronous searches (after 100 for<BR>e= xample)you should call ldap_result() with short timer and LDAP_RES_ANY<BR>a= rgue for clearing stalled or nonfreed calls. The obtained LDAPMessage can<B= R>be freed with ldap_msgfree(). Of course, you can count the asynch calls<BR>which hadn't been completed or were timed out and you can make th= e<BR>corresponding cycle for checking all iterations.<BR><BR>Please try and= let me know.<BR><BR>With respect, Serghei.<BR><BR></DIV></BLOCKQUOTE></TD>= </TR></TBODY></TABLE><BR></DIV></BLOCKQUOTE></td></tr></table><br>=0A=0A = --0-1659389023-1266011766=:33437--

1 0

Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by linamat＠telco.md 12 Feb '10

12 Feb '10

Buna ziua, domnule. 1. The pointer must be checked before operation, e.g. if (res != NULL) { ldap_msgfree (res); res = NULL; } 2. Also while processing the ext query, you should call the functions in the following manner: 2.1 ldap_search_ext() which has pointer to msgid 2.2 ldap_result() which gives the LDAPMessage structure for the msgid 2.3 if ok - ldap_parse_result() 2.4 on any stage if something is not good and you have the msgid filled with value (integer, typicaly more then 1) you should call ldap_abandon_ext() for that msgid 2.5 Finish with ldap_msgfree() 3. Periodically between the asynchronous searches (after 100 for example)you should call ldap_result() with short timer and LDAP_RES_ANY argue for clearing stalled or nonfreed calls. The obtained LDAPMessage can be freed with ldap_msgfree(). Of course, you can count the asynch calls which hadn't been completed or were timed out and you can make the corresponding cycle for checking all iterations. Please try and let me know. With respect, Serghei.

1 0

Re: (ITS#6456) Feature Request
by j＠gropefruit.com 12 Feb '10

12 Feb '10

... bump .... I would like *some* kind of acknowledgment of this ticket. Is this a = good idea? Bad idea? Any response whatsoever?=

1 0

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by j＠gropefruit.com 12 Feb '10

12 Feb '10

Pierangelo,=20 Thanks for responding. Here are some hopefully helpful answers: We have an Openfire (Java-based XMPP server, supporting ldap user/group = lookups) server that will, when deployed, have thousands of users. = Openfire works quite well with openldap, however we wanted to avoid = manually maintaining the group objects since (as I said) they would be = highly populated. Openfire supports two types of groups (in their terms): posix and = non-posix. Basically what this means is that when in posix mode, = Openfire looks for groups (e.g: cn=3Dusers) that contain UID-like = objects (single username strings). When in NON-POSIX mode, however, = Openfire will look for groups that contain DN-based members. =20 The member Attribute names (e.g: memberUid, uniqueMember, etc) are fully = configurable to openfire, but we had limited success when trying = different permutations. Some attribute-mappings work, some do not. = Eventually, we found that the following works for Openfire: overlay dynlist dynlist-attrset groupOfURLs memberURL memberUid With this record being returned when queried: dn: cn=3Dusers,cn=3Dgroups,dc=3Dexample,dc=3Dcom cn: users memberURL: = ldap:///cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom?uid?one?(objectClass=3D= simpleSecurityObject) objectClass: groupOfURLs memberUid: uid=3Dopenfire-admin,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom= memberUid: uid=3Duser1,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom memberUid: uid=3Duser2,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom memberUid: uid=3Duser3,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom memberUid: uid=3Duser4,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom memberUid: uid=3Duser5,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom memberUid: uid=3Duser6,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom memberUid: uid=3Duser7,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom memberUid: uid=3Duser8,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom memberUid: uid=3Duser9,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom I know this doesn't look right (obviously memberUid is not typically a = DN-based value) BUT THIS WORKS FOR OPENFIRE (which in the end, will be = the only client that makes use of this record). We'd prefer to use = DN-based member groups (e.g: this would be "Non-Posix" groups to = openfire) since this is the only method that works with Openfire. HOWEVER on the other side of the situation, we want to begin using = Dynamic Posix Groups, like so: overlay dynlist dynlist-attrset posixGroup memberURL memberUid:uid With this record being returned when queried: dn: cn=3Dadmins,cn=3Dposix,cn=3Dgroups,dc=3Dexample,dc=3Dcom objectClass: posixGroup objectClass: top objectClass: extensibleObject cn: systems gidNumber: 9001 memberURL: = ldap:///cn=3Dplain,cn=3Dauth,dc=3Dexample,dc=3Dcom?uid?one?(objectClass=3D= adminUser) memberUid: admin1 memberUid: admin2 memberUid: admin3 memberUid: admin4 memberUid: admin5 .... Which works wonderfully! Using shell commands like 'id' , 'groups' = will work quite nicely on the posix/shell level. But all goes to crap when combining the above dynlist-attrsets. As I = said, only one seems to be evaluated. I have tried incorporating the = optional URI parameter into the dynlist-attrsets, but this totally broke = the groups altogether (didn't expand at all). I guess I don't understand what role the first ObjectClass listed in the = dynlist-attrset parameter plays - i assumed it would act appropriately = for objects that are using the same OC that is listed in the rule. Hope this clarifies the situation for you. Thanks again for your time = ...... J=

1 0

(ITS#6472) Syncrepl : loop problem with moddn on a new node
by julien.combes＠i-carre.net 12 Feb '10

12 Feb '10

Full_Name: Julien COMBES Version: 2.4.21 OS: Debian 5.0.4 URL: ftp://ftp.openldap.org/incoming/its-syncrepl-loop-moddn.tar.bz2 Submission from: (NULL) (212.23.175.185) Hello, I think I have found a loop problem with syncrepl replication with openldap 2.4.21, BDB 4.7.25 with all patches and hdb database. The problem appears sometimes when an entry is moved with "modrdbn -s" in a node which has just been created. I have reproduced the problem with the creation of a node and a moddn while the consumer was stopped and then restarted after. The problem follows these steps : - When it starts, the consumer does a request objectClass=* on the provider : Feb 12 09:09:19 ldapma24-ida01 slapd[30445]: conn=1007 op=1 SRCH base="dc=my,dc=domain" scope=2 deref=0 filter="(objectClass=*)" - The consumer finds the modrdn and tries to do this : Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: ==>hdb_modrdn(cn=user1,ou=A,dc=my,dc=domain,cn=user1,ou=X,dc=my,dc=domain) - The consumer fails with these errors : Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: => hdb_dn2id("ou=x,dc=my,dc=domain") Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: hdb_modrdn: newSup(ndn=ou=x,dc=my,dc=domain) not here! Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: send_ldap_result: conn=-1 op=0 p=0 Feb 12 09:09:19 ldapra24-ida01 slapd[12156]: send_ldap_result: err=32 matched="" text="new superior not found" - The consumer retries the request objectClass=* on the provider and loops on the problem. The replication doesn't work anymore. To reproduce the problem, I have used these steps : - start an empty provider - ldapadd the entries in mydomain.ldif ldapadd -x -h 127.0.0.1 -D "dc=my,dc=domain" -W -f mydomain.ldif - start the consumer. - stop the consumer when replication is finished - ldapadd the new node ldapadd -x -h 127.0.0.1 -D "dc=my,dc=domain" -W -f add.ldif - modrdn -s ldapmodrdn -x -h 127.0.0.1 -D "dc=my,dc=domain" -W -r -s "ou=X,dc=my,dc=domain" "cn=user1,ou=A,dc=my,dc=domain" "cn=user1" - start the consumer I join in its-syncrepl-loop-moddn.tar.bz2 : - slapd.conf of provider and consummer - log files of provider and consummer - mydomain.ldif and add.ldif regards,

1 0

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by masarati＠aero.polimi.it 12 Feb '10

12 Feb '10

> While using the dynlist.la overlay, I found that it is only observing the > bottom-most dynlist-attrset statement. > > For example: > > dynlist-attrset groupOfURLs memberURL <--- ignored > dynlist-attrset posixGroup memberURL memberUid:uid <--- observed > > Individually (one at a time) each one of these statements does exactly > what we > need. When combined, however, all dynamic groups are indiscriminately > expanded > using one attrset "method". In the above example, all dynamic groups are > expanded to the simple UID field (like a posix group). The groupOfURLs > attrset > rule (what would normally generate simple DN-member groups) is completely > ignored. Not quite sure what you're trying to accomplish; could you send an LDIF excerpt of your dynamic groups (significantly the memberURL values), a description of what you expect and an example of what you get? > I've read the manpage, and although I don't see anything that says only > one will > be observed, I wanted to check with someone here to make sure this isn't a > bug. > If it isn't a bug, rather a feature, perhaps this topic should be expanded > in > the next manpage revision. p.

1 0

(ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by j＠gropefruit.com 11 Feb '10

11 Feb '10

Full_Name: J Version: 2.4.20 OS: Debian-Lenny/amd64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (68.15.14.98) While using the dynlist.la overlay, I found that it is only observing the bottom-most dynlist-attrset statement. For example: dynlist-attrset groupOfURLs memberURL <--- ignored dynlist-attrset posixGroup memberURL memberUid:uid <--- observed Individually (one at a time) each one of these statements does exactly what we need. When combined, however, all dynamic groups are indiscriminately expanded using one attrset "method". In the above example, all dynamic groups are expanded to the simple UID field (like a posix group). The groupOfURLs attrset rule (what would normally generate simple DN-member groups) is completely ignored. I've read the manpage, and although I don't see anything that says only one will be observed, I wanted to check with someone here to make sure this isn't a bug. If it isn't a bug, rather a feature, perhaps this topic should be expanded in the next manpage revision. Let me know, thanks. J

1 0

Re: (ITS#6455) Able to crash slapd while using back_ldap
by j＠gropefruit.com 11 Feb '10

11 Feb '10

I am unable to reproduce this error. My peers and I believe this may = have been something unrelated to slapd specifically. You may close. Sorry.

1 0

(ITS#6470) slapd dying under load
by bmaupin＠uta.edu 10 Feb '10

10 Feb '10

Full_Name: Bryan Maupin Version: 2.4.21 OS: Red Hat Enterprise Linux 5.4 URL: http://omega.uta.edu/~bmaupin/bryan-maupin-100210.txt Submission from: (NULL) (129.107.38.77) About 2 months ago we upgraded from OpenLDAP 2.3 to OpenLDAP 2.4.19. All seemed well for about 4 weeks, and then slapd started dying on our replica servers. It frequently correlates with a CPU load spike, but not always. Available memory doesn't seem to be an issue. These problems didn't show up during testing, and don't seem to have affected the master, which has been running without stopping for the last 2 months, so the problems only seem to manifest themselves under production load. In our /var/log/messages we get messages like: Jan 15 16:58:03 kernel: slapd[22663] general protection rip:2ac667af65cc rsp:4659d970 error:0 Jan 16 15:42:34 kernel: slapd[10272] general protection rip:2b71f6c6d9c4 rsp:45441980 error:0 Jan 16 17:20:01 kernel: slapd[7538] general protection rip:2aec51954ae0 rsp:449518d0 error:0 Jan 19 13:38:46 kernel: slapd[2821] general protection rip:2aeac3070ae0 rsp:4918f8d0 error:0 Quanah Gibson-Mount told me to upgrade OpenLDAP and tcmalloc, so I did, but it didn't fix the problem. We're running OpenLDAP 2.4.21 on RHEL 5.4, with Heimdal 1.2.1-3, OpenSSL 0.9.8k, Cyrus-SASL 2.1.23, BDB 4.7.25 (with patches), Google tcmalloc (minimal) 1.5. Backtrace is available here: http://omega.uta.edu/~bmaupin/bryan-maupin-100210.txt Thanks.

1 0

Re: (ITS#6365) Bad slapcat output when slapd running
by apm＠mutex.dk 05 Feb '10

05 Feb '10

Howard Chu wrote: >> If I can't trust slapcat during this >> phase, how can I trust slapcat for backups? > > Does slapcat behave this way on the active server? Yes. Sorry for the delay, but I've only just confirmed it now. The passive server needed to be moved, so I took it completely offline. Now there's only the active server and a backup shows the same result. Running slapcat while slapd is running produced invalid LDIF. Running slapcat after slapd is stopped produced OK LDIF - at least once. slapd has since been upgraded to 2.4.21. /Peter

1 0

Re: (ITS#6465) startup error after converting to slapd-config
by gerard.ranke＠kmt.hku.nl 05 Feb '10

05 Feb '10

Problem solved! olcSyncrepl now reads: olcSyncrepl: rid=001 provider=ldap://masterldap.example.com:389 bindmethod=simple timeout =0 network-timeout=0 binddn="cn=dsyncuser,dc=example,dc=com" credentials="xxxxxxx " starttls=critical tls_cert="/usr/ssl/certs/examplewildcard.cert" tl s_key="/usr/ssl/certs/examplewildcard.key" tls_cacert="/usr/ ssl/certs/cacert_root.crt" tls_reqcert=demand tls_crlcheck=none filter="(obje ctClass=*)" searchbase="dc=example,dc=com" scope=sub attrs="*,+" schemachecking=of f type=refreshAndPersist retry="5 5 10 +" so the 'uri=""' string is no longer present, and slapd starts normally after converting. Thanks for the quick fix! Best, gerard

1 0

Re: (ITS#6465) startup error after converting to slapd-config
by rhafer＠suse.de 03 Feb '10

03 Feb '10

Am Mittwoch 03 Februar 2010 13:10:04 schrieb gerard.ranke(a)kmt.hku.nl: > Hi Ralf, > > Ralf Haferkamp wrote: > > A fix is in HEAD now (servers/slapd/config.c rev 1.513) please test. > > I'm afraid I need a little guidance here. To test the fix, I replaced > the config.c from 2.4.21 with rev 1.513, but I got the errors below. > I'm guessing I'm being naive to think this would work, and that I > need to d'l the complete HEAD to compile, but how would I do that? Either that. Or you could get the diff from 1.512 to 1.153 from cvs and apply that on your 2.4.21 tree. > Cvs needs a module name, and I tried 'HEAD' and > 'OPENLDAP_REL_ENG_2_4' but these names couldn't be found. I couldn't > find anything else in the devel faq and website that seems like a > candidate for a module name, so could you please give me some > pointers? You can find instruction howto checkout OpenLDAP from cvs here: http://www.openldap.org/software/repo.html#AnonCVS Further up on that page you will also find a table listing valid modules (you want "ldap"). -- Ralf

1 0

Re: (ITS#6465) startup error after converting to slapd-config
by gerard.ranke＠kmt.hku.nl 03 Feb '10

03 Feb '10

Hi Ralf, Ralf Haferkamp wrote: > A fix is in HEAD now (servers/slapd/config.c rev 1.513) please test. I'm afraid I need a little guidance here. To test the fix, I replaced the config.c from 2.4.21 with rev 1.513, but I got the errors below. I'm guessing I'm being naive to think this would work, and that I need to d'l the complete HEAD to compile, but how would I do that? Cvs needs a module name, and I tried 'HEAD' and 'OPENLDAP_REL_ENG_2_4' but these names couldn't be found. I couldn't find anything else in the devel faq and website that seems like a candidate for a module name, so could you please give me some pointers? Many thanks in advance, gerard cc-1020 c99: ERROR File = config.c, Line = 1222 The identifier "slap_keepalive" is undefined. slap_keepalive *sk = (slap_keepalive *)bc; ^ cc-1020 c99: ERROR File = config.c, Line = 1222 The identifier "sk" is undefined. slap_keepalive *sk = (slap_keepalive *)bc; ^ cc-1029 c99: ERROR File = config.c, Line = 1222 An expression is expected at this point. slap_keepalive *sk = (slap_keepalive *)bc; ^ cc-1065 c99: ERROR File = config.c, Line = 1222 A semicolon is expected at this point. slap_keepalive *sk = (slap_keepalive *)bc; ^ cc-1020 c99: ERROR File = config.c, Line = 1238 The identifier "slap_keepalive" is undefined. slap_keepalive *sk = (slap_keepalive *)bc; ^ cc-1020 c99: ERROR File = config.c, Line = 1238 The identifier "sk" is undefined. slap_keepalive *sk = (slap_keepalive *)bc; ^ cc-1029 c99: ERROR File = config.c, Line = 1238 An expression is expected at this point. slap_keepalive *sk = (slap_keepalive *)bc; ^ cc-1065 c99: ERROR File = config.c, Line = 1238 A semicolon is expected at this point. slap_keepalive *sk = (slap_keepalive *)bc; ^ cc-1065 c99: ERROR File = config.c, Line = 1239 A semicolon is expected at this point. slap_keepalive sk2; ^ cc-1020 c99: ERROR File = config.c, Line = 1242 The identifier "sk2" is undefined. sk2.sk_idle = 0; ^ cc-1020 c99: ERROR File = config.c, Line = 1246 The identifier "sk2" is undefined. sk2.sk_idle = strtol( s, &next, 10 ); ^ cc-1020 c99: ERROR File = config.c, Line = 1259 The identifier "sk2" is undefined. sk2.sk_probes = 0; ^ cc-1020 c99: ERROR File = config.c, Line = 1263 The identifier "sk2" is undefined. sk2.sk_probes = strtol( s, &next, 10 ); ^ cc-1020 c99: ERROR File = config.c, Line = 1276 The identifier "sk2" is undefined. sk2.sk_interval = 0; ^ cc-1020 c99: ERROR File = config.c, Line = 1280 The identifier "sk2" is undefined. sk2.sk_interval = strtol( s, &next, 10 ); ^ cc-1020 c99: ERROR File = config.c, Line = 1290 The identifier "sk2" is undefined. *sk = sk2; ^ cc-1565 c99: ERROR File = config.c, Line = 1336 The struct "slap_bindconf" has no field "sb_keepalive". { BER_BVC("keepalive="), offsetof(slap_bindconf, sb_keepalive), 'x', 0, (slap_verbmasks *)slap_keepalive_parse }, ^ ( warnings skipped... ) cc-1565 c99: ERROR File = config.c, Line = 1889 The struct "slap_bindconf" has no field "sb_keepalive". if ( sb->sb_keepalive.sk_idle ) { ^ cc-1565 c99: ERROR File = config.c, Line = 1890 The struct "slap_bindconf" has no field "sb_keepalive". ldap_set_option( ld, LDAP_OPT_X_KEEPALIVE_IDLE, &sb->sb_keepalive.sk_idle ); ^ cc-1565 c99: ERROR File = config.c, Line = 1893 The struct "slap_bindconf" has no field "sb_keepalive". if ( sb->sb_keepalive.sk_probes ) { ^ cc-1565 c99: ERROR File = config.c, Line = 1894 The struct "slap_bindconf" has no field "sb_keepalive". ldap_set_option( ld, LDAP_OPT_X_KEEPALIVE_PROBES, &sb->sb_keepalive.sk_probes ); ^ cc-1565 c99: ERROR File = config.c, Line = 1897 The struct "slap_bindconf" has no field "sb_keepalive". if ( sb->sb_keepalive.sk_interval ) { ^ cc-1565 c99: ERROR File = config.c, Line = 1898 The struct "slap_bindconf" has no field "sb_keepalive". ldap_set_option( ld, LDAP_OPT_X_KEEPALIVE_INTERVAL, &sb->sb_keepalive.sk_interval );

1 0

Re: (ITS#6469) push replication entryCSN of database suffix out of sync
by rhafer＠suse.de 03 Feb '10

03 Feb '10

Am Mittwoch 03 Februar 2010 09:39:19 schrieb hyc(a)symas.com: > rhafer(a)suse.de wrote: > > Am Dienstag 02 Februar 2010 23:30:23 schrieb hyc(a)symas.com: > >> But how did the suffix entry get created without an entryCSN in the > >> first place? The MOD that updates the contextCSN doesn't happen > >> until after the suffix entry already exists. > > > > It wasn't created without an entryCSN. It always had one. But the > > MOD to update the contextCSN (coming from the provider) doesn't > > contain one. So bdb_modify() will call slap_mods_opattrs() to add > > entryCSN to the MOD operation. The easiest fix is probably to never > > touch the opattrs if "updatedn" is doing MODs, though I am not yet > > sure if it might break something. Currently my fix (not committed > > yet) only skips the slap_mods_opattrs() step if "updatedn" it is > > doing a MOD on contextCSN. > > Ah, got it. Yes, sounds like your fix is fine. Do you think it's fine to always skip slap_mods_opattrs() if "updatedn" is writing? Or should I check for contextCSN MODs specifically? > Historically the updatedn user (e.g. slurpd) has always provided all of > the operational attributes in its updates. -- Ralf

1 0

Re: (ITS#6469) push replication entryCSN of database suffix out of sync
by hyc＠symas.com 03 Feb '10

03 Feb '10

rhafer(a)suse.de wrote: > Am Dienstag 02 Februar 2010 23:30:23 schrieb hyc(a)symas.com: >> But how did the suffix entry get created without an entryCSN in the >> first place? The MOD that updates the contextCSN doesn't happen until >> after the suffix entry already exists. > It wasn't created without an entryCSN. It always had one. But the MOD to > update the contextCSN (coming from the provider) doesn't contain one. So > bdb_modify() will call slap_mods_opattrs() to add entryCSN to the MOD > operation. The easiest fix is probably to never touch the opattrs if > "updatedn" is doing MODs, though I am not yet sure if it might break > something. Currently my fix (not committed yet) only skips the > slap_mods_opattrs() step if "updatedn" it is doing a MOD on contextCSN. Ah, got it. Yes, sounds like your fix is fine. Historically the updatedn user (e.g. slurpd) has always provided all of the operational attributes in its updates. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6469) push replication entryCSN of database suffix out of sync
by rhafer＠suse.de 03 Feb '10

03 Feb '10

Am Dienstag 02 Februar 2010 23:30:23 schrieb hyc(a)symas.com: > ralf(a)OpenLDAP.org wrote: > > Full_Name: Ralf Haferkamp > > Version: RE24, HEAD > > OS: > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (89.166.208.247) > > Submitted by: ralf > > > > > > When using push-based replication (syncrepl-proxy) the entryCSN of > > the consumer's server's suffix entry (the one that also holds the > > contextCSN Attribute) is not in sync with the value on the > > provider. (Other operational Attributes are out of sync as well) > > > > This is because the MOD Operation to update the contextCSN (sent by > > the provider) does not contain any other operational Attributes. > > That causes the consumer to add those attributes itself. > > > > I guess the problem is mostly cosmetic, but I'll submit a fix > > anyway. (not calling slap_mods_opattrs() if the updatedn modifies > > "contextCSN") > > But how did the suffix entry get created without an entryCSN in the > first place? The MOD that updates the contextCSN doesn't happen until > after the suffix entry already exists. It wasn't created without an entryCSN. It always had one. But the MOD to update the contextCSN (coming from the provider) doesn't contain one. So bdb_modify() will call slap_mods_opattrs() to add entryCSN to the MOD operation. The easiest fix is probably to never touch the opattrs if "updatedn" is doing MODs, though I am not yet sure if it might break something. Currently my fix (not committed yet) only skips the slap_mods_opattrs() step if "updatedn" it is doing a MOD on contextCSN. -- Ralf

1 0

Re: (ITS#6469) push replication entryCSN of database suffix out of sync
by hyc＠symas.com 02 Feb '10

02 Feb '10

ralf(a)OpenLDAP.org wrote: > Full_Name: Ralf Haferkamp > Version: RE24, HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (89.166.208.247) > Submitted by: ralf > > > When using push-based replication (syncrepl-proxy) the entryCSN of the > consumer's server's suffix entry (the one that also holds the contextCSN > Attribute) is not in sync with the value on the provider. (Other operational > Attributes are out of sync as well) > > This is because the MOD Operation to update the contextCSN (sent by the > provider) does not contain any other operational Attributes. That causes the > consumer to add those attributes itself. > > I guess the problem is mostly cosmetic, but I'll submit a fix anyway. (not > calling slap_mods_opattrs() if the updatedn modifies "contextCSN") > But how did the suffix entry get created without an entryCSN in the first place? The MOD that updates the contextCSN doesn't happen until after the suffix entry already exists. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by rmeggins＠redhat.com 02 Feb '10

02 Feb '10

New and improved patch, to address issues mentioned by Howard, and to clean up some memory leaks. ftp://ftp.openldap.org/incoming/openldap-2.4.21-tls_m_c-InitContext-PEM-201… Note: This new version depends on Mozilla NSS 3.12.6 (currently unreleased) and currently unreleased patches of PEM NSS in order to avoid a couple of memory leaks.

1 0

(ITS#6469) push replication entryCSN of database suffix out of sync
by ralf＠OpenLDAP.org 02 Feb '10

02 Feb '10

Full_Name: Ralf Haferkamp Version: RE24, HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.208.247) Submitted by: ralf When using push-based replication (syncrepl-proxy) the entryCSN of the consumer's server's suffix entry (the one that also holds the contextCSN Attribute) is not in sync with the value on the provider. (Other operational Attributes are out of sync as well) This is because the MOD Operation to update the contextCSN (sent by the provider) does not contain any other operational Attributes. That causes the consumer to add those attributes itself. I guess the problem is mostly cosmetic, but I'll submit a fix anyway. (not calling slap_mods_opattrs() if the updatedn modifies "contextCSN")

1 0

Re: (ITS#6468) ACLs in subordinate databases can be ignored
by rein＠OpenLDAP.org 02 Feb '10

02 Feb '10

On 02/02/2010 04:25 PM, Hallvard B Furuseth wrote: > Hold on. Is the current behavior self-consistent, i.e. one could call > it an undocumented feature? If so someone may have noticed this and > written their ACLs accordingly. It's not friendly to change the > meaning of existing installations' ACLs in the middle of RE24. > > OTOH if current behavior is broken even as a "feature", fix away. > E.g. if clients can choose which ACLs will apply in the subordinate > by picking a base DN inside vs outside the subordinate. From my analyzis of the problem, the subordinate ACLs are used in all cases except when syncprov desides which "live" modifications it should replicate to its consumers. Searching with the credentials used by the syncrepl consumer gives me the attributes and entries my subordinate ACLs allows, and they are replicated during the refresh phase. But access to entries and/or attributes being modified during the persistent phase are rejected. But yes, the change should be analyzed by somebody else before being included in a release. Rein

1 0

Re: (ITS#6468) ACLs in subordinate databases can be ignored
by h.b.furuseth＠usit.uio.no 02 Feb '10

02 Feb '10

Hold on. Is the current behavior self-consistent, i.e. one could call it an undocumented feature? If so someone may have noticed this and written their ACLs accordingly. It's not friendly to change the meaning of existing installations' ACLs in the middle of RE24. OTOH if current behavior is broken even as a "feature", fix away. E.g. if clients can choose which ACLs will apply in the subordinate by picking a base DN inside vs outside the subordinate. -- Hallvard

1 0

(ITS#6468) ACLs in subordinate databases can be ignored
by rein＠OpenLDAP.org 02 Feb '10

02 Feb '10

Full_Name: Rein Tollevik Version: CVS HEAD OS: Irrelevant URL: Submission from: (NULL) (2a01:600:0:1:21c:23ff:feab:61cd) Submitted by: rein In a glued database configuration where overlays (syncprov, accesslog) are stacked on top of the glue overlay, ACL evaluation initiated from these overlays can be evaluated by the superior glue database and not the subordinate database where the entry actually exist. I.e, ACLs defined in the subordinate databases are ignored in these cases. A fix that implements bi_access_allowed in the glue overlay is coming, it delegates the call to the actual backend where the entry being referenced exist. An alternative approach I considered was to require the overlays to call select_backend() to find the actual backend where the entry exist, but that would imo obfuscate the modularization of the code. -- Rein Tollevik Basefarm AS

1 0

Re: (ITS#6465) startup error after converting to slapd-config
by gerard.ranke＠kmt.hku.nl 02 Feb '10

02 Feb '10

Ralf Haferkamp wrote: > A fix is in HEAD now (servers/slapd/config.c rev 1.513) please test. Thanks! Hopefully I can compile & test tomorrow, I'll let you know. Best, gerard

1 0

Re: (ITS#6465) startup error after converting to slapd-config
by Ralf Haferkamp 02 Feb '10

02 Feb '10

A fix is in HEAD now (servers/slapd/config.c rev 1.513) please test.

1 0

Re: (ITS#6465) startup error after converting to slapd-config
by Ralf Haferkamp 02 Feb '10

02 Feb '10

This got introduced by the fix for ITS#6419. I am currently working on a fix.

1 0

(ITS#6467) syncrepl enhancements
by hyc＠OpenLDAP.org 02 Feb '10

02 Feb '10

Full_Name: Howard Chu Version: 2.5 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.212) Submitted by: hyc Syncrepl refreshes can be very expensive without a sessionlog, and the syncprov sessionlog is inadequate because it's in-memory only, and doesn't survive a restart. Syncprov should be extended to take advantage of the accesslog overlay if it is available.

1 0

Re: (ITS#6464) Buffer overflow
by csdr＠lthd.com 01 Feb '10

01 Feb '10

Sorry. I hope this helps: http://lthd.com/slapd.out On 01/31/2010 01:05 AM, Howard Chu wrote: > csdr(a)lthd.com wrote: >> Full_Name: Chis-Serban Dinu-Razvan >> Version: 2.4.21 >> OS: Fedora 12 >> URL: http://lthd.com/out1.txt >> Submission from: (NULL) (193.231.233.40) >> >> >> I have a master ldap server running openldap 2.4.21 and 3 replicas >> running >> 2.4.15 and 2.4.19 and I when I try to delete/rename an object, the >> master dies >> with an buffer overflow error. I mention that before the master was >> 2.4.15 and >> the replica running 2.4.19 died. I have updated the master to 2.4.19 >> and it >> start dyeing. Then I upgraded it to 2.4.21 an it still dies. It dies >> even if the >> syncprov is off. >> > Please provide a stack trace from this crash. Be sure to compile with > debug symbols enabled and no optimization, otherwise we won't be able > to track anything down. >

1 0

Re: (ITS#6466) certificateListValidate rejects valid X.509 CRLs (but not RFC-compliant)
by masarati＠aero.polimi.it 01 Feb '10

01 Feb '10

hyc(a)symas.com wrote: >> BTW, what do you mean by "needs some thought" (in the ticket notes)? > > I hadn't decided yet if slapd should log a warning for this or not. A warning, to be useful, should allow to clearly identify the broken piece of data. Where the issue is identified, there's no way to find out the DN of the entry that contains the datum. All you could use is the certificate's content (e.g. issuer DN and so); not sure how helpful it would be. p.

1 0

Re: (ITS#6466) certificateListValidate rejects valid X.509 CRLs (but not RFC-compliant)
by hyc＠symas.com 31 Jan '10

31 Jan '10

Erwann Abalea wrote: > Hodie III Kal. Feb. MMX, Howard Chu scripsit: (Sorry, just had to laugh, using a ~3000 year old language in email...) >> erwann.abalea(a)keynectis.com wrote: >> Also note that, technically, LDAP is defined to conform to the 1993 >> edition of the X.500 specs, and X.509(1993) makes no such allowance >> here. > > I didn't know that LDAP was designed to conform to a specific edition > of the standard. Isn't that strange? After all, it should also refuse > to handle X.509v2 CRLs, and X.509v3 certificates, which appear for the > first time in the 1997 edition. > Anyway, I hadn't thought about looking at older revisions of the X.509 > standard. You're right, my 1997 edition doesn't say anything about > this, and my 2000 edition (a french version) has the same text as the > 2005 one. See RFC4510, section 2. Yes, it's certainly an inconsistency in the LDAP spec, that RFC4513 requires use of subjectAltNames which clearly require X.509v3 certs but the only normative references to the necessary edition of X.509 is outside the core specification. (Looking again I see that RFC4523 references X.509(2000) so it appears that some portions of newer X.500 editions are being incorporated, piecemeal...) > Anyway, thank you again. I'll test the head version and will come back > later. > BTW, what do you mean by "needs some thought" (in the ticket notes)? I hadn't decided yet if slapd should log a warning for this or not. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6466) certificateListValidate rejects valid X.509 CRLs (but not RFC-compliant)
by erwann.abalea＠keynectis.com 31 Jan '10

31 Jan '10

Hodie III Kal. Feb. MMX, Howard Chu scripsit: > erwann.abalea(a)keynectis.com wrote: > >When no certificate is revoked, the revokedCertificate element SHOULD be > >omitted, instead of being included as an empty SEQUENCE OF SEQUENCE. RFC5280 has > >changed the SHOULD into a MUST, but I don't think this is checked by the > >function. I think it only skips over the next element (in my case, the > >crlExtensions). > > Thanks for the report. The code in CVS HEAD has been patched to > silently accept this case. However, it's worth pointing out that > even in X.509(2005): Thank you for having corrected it. > >>>> > If none of the certificates covered by this CRL have been revoked, > it is strongly recommended that > revokedCertificates parameter be omitted from the CRL, rather than being > included with an empty SEQUENCE. > <<<< That's what I meant to write when I wrote that the element SHOULD be omitted. X.509 doesn't prevent such an empty sequence, it only strongly recommends to avoid it. A strong recommendation in ISO terminology is as a SHOULD in RFC2119 meaning. You're right, here. > Also note that, technically, LDAP is defined to conform to the 1993 > edition of the X.500 specs, and X.509(1993) makes no such allowance > here. I didn't know that LDAP was designed to conform to a specific edition of the standard. Isn't that strange? After all, it should also refuse to handle X.509v2 CRLs, and X.509v3 certificates, which appear for the first time in the 1997 edition. Anyway, I hadn't thought about looking at older revisions of the X.509 standard. You're right, my 1997 edition doesn't say anything about this, and my 2000 edition (a french version) has the same text as the 2005 one. > We may consider logging a warning for this case. What software > generated this CRL? It seems to be defective... At first, I also thought it was defective. But after all, the standard doesn't say that this revokedCertificates element MUST be eliminated when no certificate is revoked (I use RFC2119 terminology here, but you certainly got it). I certainly will produce a warning to the software vendor, though. In general, I tend to follow "SHOULD" rules. I don't know what software produced this CRL (yet), I only know who uses it (one of our customers). I'll get in touch with them for that. In the same time, I'll check that we correctly do our job (we're also a PKI software vendor). Anyway, thank you again. I'll test the head version and will come back later. BTW, what do you mean by "needs some thought" (in the ticket notes)? -- Erwann ABALEA <erwann.abalea(a)keynectis.com> ----- "Common sense is the collection of prejudices acquired by age 18." - Albert Einstein

1 0

Re: (ITS#6464) Buffer overflow
by hyc＠symas.com 30 Jan '10

30 Jan '10

csdr(a)lthd.com wrote: > Full_Name: Chis-Serban Dinu-Razvan > Version: 2.4.21 > OS: Fedora 12 > URL: http://lthd.com/out1.txt > Submission from: (NULL) (193.231.233.40) > > > I have a master ldap server running openldap 2.4.21 and 3 replicas running > 2.4.15 and 2.4.19 and I when I try to delete/rename an object, the master dies > with an buffer overflow error. I mention that before the master was 2.4.15 and > the replica running 2.4.19 died. I have updated the master to 2.4.19 and it > start dyeing. Then I upgraded it to 2.4.21 an it still dies. It dies even if the > syncprov is off. > Please provide a stack trace from this crash. Be sure to compile with debug symbols enabled and no optimization, otherwise we won't be able to track anything down. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6466) certificateListValidate rejects valid X.509 CRLs (but not RFC-compliant)
by hyc＠symas.com 30 Jan '10

30 Jan '10

erwann.abalea(a)keynectis.com wrote: > Full_Name: Erwann Abalea > Version: 2.4.17 > OS: Debian/testing > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.167.155.1) > > > As indicated in the subject, certificateListValidate() doesn't validate some > valid CRLs. Those CRLs are valid from X.509 point of view, but do not conform to > RFC5280 (which is only a profile of the standard). > > When no certificate is revoked, the revokedCertificate element SHOULD be > omitted, instead of being included as an empty SEQUENCE OF SEQUENCE. RFC5280 has > changed the SHOULD into a MUST, but I don't think this is checked by the > function. I think it only skips over the next element (in my case, the > crlExtensions). Thanks for the report. The code in CVS HEAD has been patched to silently accept this case. However, it's worth pointing out that even in X.509(2005): >>>> If none of the certificates covered by this CRL have been revoked, it is strongly recommended that revokedCertificates parameter be omitted from the CRL, rather than being included with an empty SEQUENCE. <<<< Also note that, technically, LDAP is defined to conform to the 1993 edition of the X.500 specs, and X.509(1993) makes no such allowance here. We may consider logging a warning for this case. What software generated this CRL? It seems to be defective... > Here's a real-life CRL: > certificateRevocationList;binary:: MIIBPTCBpwIBATANBgkqhkiG9w0BAQUFADAkMQswCQY > DVQQGEwJGUjEVMBMGA1UEChMMR0lQLUNQUy1URVNUFw0wOTA5MTcxMDEyNTdaFw0xMDA2MjQxMDEy > NTdaMACgTTBLMB8GA1UdIwQYMBaAFOH6F/gUI8Xen3tJVqLlQphs5EovMAoGA1UdFAQDAgECMBwGA > 1UdEgQVMBOBEWFjLWdpcEBnaXAtY3BzLmZyMA0GCSqGSIb3DQEBBQUAA4GBAByCwHi4fZG95ScpLO > 2HW+5I1zeodXlbTOCgnbLVLLz0WjXXZpa5ecn2aHpqrc5L70UIKBhrk/LJ8+y03UBtx6z1gdGNL3u > +rbVQcMgbKJ5AbLojfyWeS4d6n8TZBlM0Wd5eJ6AlwPKRvNV//QH3vjMPVWeD2XYtwQhBYqEGJrvn > > And a real-life deltaCRL: > deltaRevocationList;binary:: MIIBTjCBuAIBATANBgkqhkiG9w0BAQUFADAkMQswCQYDVQQGE > wJGUjEVMBMGA1UEChMMR0lQLUNQUy1URVNUFw0wODEyMjQwMzAwMjNaFw0wODEyMzAwMzAwMjNaMA > CgXjBcMB8GA1UdIwQYMBaAFOH6F/gUI8Xen3tJVqLlQphs5EovMAsGA1UdFAQEAgIKAjAOBgNVHRs > BAf8EBAICCgEwHAYDVR0SBBUwE4ERYWMtZ2lwQGdpcC1jcHMuZnIwDQYJKoZIhvcNAQEFBQADgYEA > gEk/dBR5Vz+RtfBp4hpPaSX1aXFAzx6pZCSBaQ4dFfbXV9HkbPM/2dh32HRDueyhJnXmfn/m5Q9Vo > syEzF1MQEDYZV0A5Liu8oiZtY9gfe522pz7+oehZdOyzkLx6nUw6uLLTL62q8lRbDsNbZNsu22sz7 > dAucnBo63ksdGgdFQ= > > You'll see empty SEQUENCEs. Bug probably around line 314 of file schema_init.c, > but I don't know openldap internals enough to correct it by myself. > > Thanks. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6466) certificateListValidate rejects valid X.509 CRLs (but not RFC-compliant)
by erwann.abalea＠keynectis.com 29 Jan '10

29 Jan '10

Full_Name: Erwann Abalea Version: 2.4.17 OS: Debian/testing URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.167.155.1) As indicated in the subject, certificateListValidate() doesn't validate some valid CRLs. Those CRLs are valid from X.509 point of view, but do not conform to RFC5280 (which is only a profile of the standard). When no certificate is revoked, the revokedCertificate element SHOULD be omitted, instead of being included as an empty SEQUENCE OF SEQUENCE. RFC5280 has changed the SHOULD into a MUST, but I don't think this is checked by the function. I think it only skips over the next element (in my case, the crlExtensions). Here's a real-life CRL: certificateRevocationList;binary:: MIIBPTCBpwIBATANBgkqhkiG9w0BAQUFADAkMQswCQY DVQQGEwJGUjEVMBMGA1UEChMMR0lQLUNQUy1URVNUFw0wOTA5MTcxMDEyNTdaFw0xMDA2MjQxMDEy NTdaMACgTTBLMB8GA1UdIwQYMBaAFOH6F/gUI8Xen3tJVqLlQphs5EovMAoGA1UdFAQDAgECMBwGA 1UdEgQVMBOBEWFjLWdpcEBnaXAtY3BzLmZyMA0GCSqGSIb3DQEBBQUAA4GBAByCwHi4fZG95ScpLO 2HW+5I1zeodXlbTOCgnbLVLLz0WjXXZpa5ecn2aHpqrc5L70UIKBhrk/LJ8+y03UBtx6z1gdGNL3u +rbVQcMgbKJ5AbLojfyWeS4d6n8TZBlM0Wd5eJ6AlwPKRvNV//QH3vjMPVWeD2XYtwQhBYqEGJrvn And a real-life deltaCRL: deltaRevocationList;binary:: MIIBTjCBuAIBATANBgkqhkiG9w0BAQUFADAkMQswCQYDVQQGE wJGUjEVMBMGA1UEChMMR0lQLUNQUy1URVNUFw0wODEyMjQwMzAwMjNaFw0wODEyMzAwMzAwMjNaMA CgXjBcMB8GA1UdIwQYMBaAFOH6F/gUI8Xen3tJVqLlQphs5EovMAsGA1UdFAQEAgIKAjAOBgNVHRs BAf8EBAICCgEwHAYDVR0SBBUwE4ERYWMtZ2lwQGdpcC1jcHMuZnIwDQYJKoZIhvcNAQEFBQADgYEA gEk/dBR5Vz+RtfBp4hpPaSX1aXFAzx6pZCSBaQ4dFfbXV9HkbPM/2dh32HRDueyhJnXmfn/m5Q9Vo syEzF1MQEDYZV0A5Liu8oiZtY9gfe522pz7+oehZdOyzkLx6nUw6uLLTL62q8lRbDsNbZNsu22sz7 dAucnBo63ksdGgdFQ= You'll see empty SEQUENCEs. Bug probably around line 314 of file schema_init.c, but I don't know openldap internals enough to correct it by myself. Thanks.

1 0

(ITS#6465) startup error after converting to slapd-config
by gerard.ranke＠kmt.hku.nl 29 Jan '10

29 Jan '10

Full_Name: Gerard Ranke Version: 2.4.21 OS: IRIX 6.5.30 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.87.216.230) We run openLDAP 2.4.21 on one master plus 7 slaves. Some time ago ( I believe we were on 2.4.19 at the time ), I converted one of the slaves to slapd-config from slapd.conf to get myself acquainted with it, and that went without problems. Now, if I try the conversion with slaptest -f slapd.conf -F slapd.d, the conversion works ok, but slapd won't start, and gives this error: Jan 18 15:30:20 7E:example-slave slapd[1741992]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: ldapdb Jan 18 15:30:20 7U:example-slave slapd[1741992]: olcSyncrepl: value #0: <olcSyncrepl> invalid URL Jan 18 15:30:20 7U:example-slave slapd[1741992]: config error processing olcDatabase={1}hdb,cn=config: <olcSyncrepl> invalid URL Jan 18 15:30:20 7U:example-slave slapd[1741992]: slapd stopped. Jan 18 15:30:20 7U:example-slave slapd[1741992]: connections_destroy: nothing to destroy. I noticed that the olcSyncrepl in olcDatabase={1}hdb,cn=config changed from: olcSyncrepl: rid=001 provider=ldap://masterldap.example.com:389 bindmethod=simple timeout =0 network-timeout=0 binddn="cn=syncuser,dc=example,dc=com" credentials="xxxxxxxxx " starttls=critical filter="(objectClass=*)" searchbase="dc=example,dc=com" scope= sub attrs="*,+" schemachecking=off type=refreshAndPersist retry="5 5 10 +" for the older openldap version, to: olcSyncrepl: rid=001 provider=ldap://masterldap.example.com:389 uri="" bindmethod=simple timeout=0 network-timeout=0 binddn="cn=syncuser,dc=example,dc=com" credentials="xxxxxxxxx" starttls=critical tls_cert="/usr/ssl/certs/examplewildcard.cert " tls_key="/usr/ssl/certs/examplewildcard.key" tls_cacert="/usr /ssl/certs/cacert_root.crt" tls_reqcert=demand tls_crlcheck=none filter="(obj ectClass=*)" searchbase="dc=example,dc=com" scope=sub attrs="*,+" schemachecking=o ff type=refreshAndPersist retry="5 5 10 +" for 2.4.21. Notice the ' uri="" ' in the last version. Fortunately, if I remove the empty uri assignment from the ldif file, slapd starts normally. I also noticed the slaves which I converted earlier ( so which had the first olcSyncrepl 'format' above ) didn't replicate properly ( contextcsn also lagging behind ). I shut down slapd on these machines, cleaned out slapd.d, converted again, removed the 'uri=""' and restarted. After that, the replication caught up by itself. Thanks for your attention for this!

1 0

(ITS#6464) Buffer overflow
by csdr＠lthd.com 28 Jan '10

28 Jan '10

Full_Name: Chis-Serban Dinu-Razvan Version: 2.4.21 OS: Fedora 12 URL: http://lthd.com/out1.txt Submission from: (NULL) (193.231.233.40) I have a master ldap server running openldap 2.4.21 and 3 replicas running 2.4.15 and 2.4.19 and I when I try to delete/rename an object, the master dies with an buffer overflow error. I mention that before the master was 2.4.15 and the replica running 2.4.19 died. I have updated the master to 2.4.19 and it start dyeing. Then I upgraded it to 2.4.21 an it still dies. It dies even if the syncprov is off.

1 0

Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by alinachegalati＠yahoo.com 27 Jan '10

27 Jan '10

--0-1999948331-1264610847=:54320 Content-Type: text/plain; charset=us-ascii We found out that this call : ldap_msgfree(res); does not get executed because the LDAPMessage is NULL (res is null) in case the timeout is on the client side. There is any other way to clean it? --0-1999948331-1264610847=:54320 Content-Type: text/html; charset=us-ascii <table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">We found out that this call :<br><br>ldap_msgfree(res);<br><br>does not get executed because the LDAPMessage is NULL (res is null) in case the timeout is on the client side.<br><br>There is any other way to clean it?<br></td></tr></table><br> --0-1999948331-1264610847=:54320--

1 0

Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by alinachegalati＠yahoo.com 27 Jan '10

27 Jan '10

--0-1407467353-1264601923=:2093 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =A0 A similar issue was found in Netscape SDK :=A0 http://www.mail-archive.= com/mozilla-directory(a)mozilla.org/msg01734.html =0A=0A=0A --0-1407467353-1264601923=:2093 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"= top" style=3D"font: inherit;">  A similar issue was found in Netscape = SDK :  http://www.mail-archive.com/mozilla-directory@mozilla.org/msg01= 734.html<br><br></td></tr></table><br>=0A=0A --0-1407467353-1264601923=:2093--

1 0

memberof overlay
by Daniel Gomes 27 Jan '10

27 Jan '10

Dear list members, I have been trying to get the memberof overlay to work properly on slapd 2.4.19 on an Ubuntu hardy (8.04.3). After realizing (which took a while hehe) that installing OpenLDAP via apt-get wouldn't allow me to enable modules/overlays, I downloaded the source and built it manually with: ./configure --enable-overlays --enable-accesslog --enable-auditlog --enable-collect --enable-constraint --enable-dds --enable-deref --enable-dyngroup --enable-dynlist --enable-memberof --enable-ppolicy --enable-proxycache --enable-refint --enable-retcode --enable-rwm --enable-seqmod --enable-syncprov --enable-translucent --enable-unique --enable-valsort --enable-modules --with-tls (I wanted to be on the safe side so I kinda enabled everything) The server is now set up and running (with TLS and all, but I guess that's not important here). To activate the wanted overlay, I have (on my slapd.conf): modulepath /usr/local/etc/openldap/overlays/ moduleload memberof.la overlay memberof (the path is correct and I have checked the logs to make sure he was paying attention to those fields). Anyway, I starting making some experiences, and at first it seemed to be working fine. But some test cases later, the memberOf value started being incorrect, when comparing to the member attribute of the groups. Here's how to reproduce my scenario (I just tried it again, with a new database, base DN being dc=ipfn,dc=ist,dc=utl,dc=pt): First, run init.ldif (attached), which creates the usual groups and people OU's, creates 2 users followed by 2 group with one user per group. So far so good, if I make a ldapsearch based on ou=people (...) and ask for the memberOf attribute, I get: dn: ou=people,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt dn: cn=Daniel Gomes,ou=people,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt memberOf: cn=admin,ou=groups,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt dn: cn=John Smith,ou=people,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt memberOf: cn=users,ou=groups,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt ---------------------------------------- Next, I run modify.ldif (also attached) which changes the member attribute of the admin group from "cn=Daniel Gomes (...)" to "cn=John Smith (...)". We can then see that: dn: ou=groups,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt objectClass: organizationalUnit ou: groups dn: cn=admin,ou=groups,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt objectClass: groupOfNames cn: admin description: For administrators member: cn=John Smith,ou=people,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt dn: cn=users,ou=groups,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt objectClass: groupOfNames cn: users description: For users member: cn=John Smith,ou=people,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt ---------------------------------------------- Meaning, the group was successfully modified, but the previous query returns the same value: dn: ou=people,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt dn: cn=Daniel Gomes,ou=people,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt memberOf: cn=admin,ou=groups,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt dn: cn=John Smith,ou=people,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt memberOf: cn=users,ou=groups,ou=portal,dc=ipfn,dc=ist,dc=utl,dc=pt ----------------------------------------- This seems to happen only when deleting users from groups. I have tried with and without the refint overlay, if that matters for anything. Anyway, I do not see anything I can be doing wrong, so it does seem to be a bug. If I could get some info on this, I would appreciate it! Cheers, -- Daniel Gomes (SysAdmin) dgomes(a)ipfn.ist.utl.pt Ext. 3487 - 218419487 Instituto de Plasmas e usão Nuclear Instituto Superior Técnico - UTL Av. Rovisco Pais - 1049-001 Lisboa - Portugal

1 0

Re: (ITS#6462) DNS SRV records: ldaps ???
by quanah＠zimbra.com 26 Jan '10

26 Jan '10

--On Wednesday, January 27, 2010 1:28 AM +0000 jochen(a)keutel.de wrote: > Full_Name: Jochen Keutel > Version: 2.4.21 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > protocol is either "ldap" oder "ldaps". LDAPS is not a defined protocol. I would suggest using LDAP with startTLS, which is RFC Defined. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6463) dnssrv_back_referrals: ldaps not handled, search base gone
by jochen＠keutel.de 26 Jan '10

26 Jan '10

Full_Name: Jochen Keutel Version: 2.4.21 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.159.206.14) dnssrv_back_referrals() always returns ldap URLs - even when the original request was a ldaps query. Additionally only protocol and hostname are put into the URL - the search base doesn't appear any more. Problematic code: url.bv_len = STRLENOF( "ldap://" ) + strlen( hosts[i] ); url.bv_val = ch_malloc( url.bv_len + 1 ); strcpy( url.bv_val, "ldap://" ); strcpy( &url.bv_val[STRLENOF( "ldap://" )], hosts[i] ); I'm not sure whether you want me to deliver a complete patch or not ... Thanks to my colleague Manuel Gaupp for detecting this problem. Best regards, Jochen.

1 0

(ITS#6462) DNS SRV records: ldaps ???
by jochen＠keutel.de 26 Jan '10

26 Jan '10

Full_Name: Jochen Keutel Version: 2.4.21 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.159.206.14) The code for detecting LDAP servers via DNS SRV records seems to handle only ldap URLs - not ldaps URLs. Esp.: If you access an OpenLDAP server with ldaps://host1/..., then the DNS SRV code returns a URL like ldap://host2/... . So the LDAP server chains the original ldaps request as a LDAP query without TLS. This gets problematic when the (company / project) requirements clearly state that only ldaps has to be used ... The problematic code seems to be in libraries/libldap/dnssrv.c, function ldap_domain2hostlist(): request = LDAP_MALLOC(strlen(domain) + sizeof("_ldap._tcp.")); ... sprintf(request, "_ldap._tcp.%s", domain); So always "_ldap._tcp" is used (hard coded) - not "ldaps._tcp" in case of ldaps in the original query. I'd suggest to introduce a third parameter to that function: int ldap_domain2hostlist( LDAP_CONST char *protocol, LDAP_CONST char *domain, char **list ) protocol is either "ldap" oder "ldaps". The code calling this function (slapd/back-dnssrv/search.c and referral.c) has to be adjusted as well. I'm not sure whether you want me to deliver a complete patch or not ... Thanks to my colleague Manuel Gaupp for detecting this problem. Best regards, Jochen.

1 0

Re: (ITS#6457) hiding remote attribute with rwm-map in relay context crashes server
by masarati＠aero.polimi.it 25 Jan '10

25 Jan '10

Guillaume.Rousse(a)inria.fr wrote: > Le 18/01/2010 17:13, masarati(a)aero.polimi.it a écrit : >> Could not reproduce. Apparently, it's something else that's creating >> hassle. Please provide a stack backtrace. > > Actually, it's an assertion failure un entry.c: > slapd: entry.c:483: entry_clean: Assertion `e->e_private == ((void *)0)' > failed. > Abandon > > Here the backtrace, but compilation optimisation may hinder its usability: Well, at least it shows where the failure is. However, since I can't reproduce it, I'll need your (sanitized) slapd.conf, a LDIF to load and the operation that causes the failure. p.

1 0

Re: (ITS#6460) SASL EXTERNAL fails with long certificate serial numbers
by masarati＠aero.polimi.it 25 Jan '10

25 Jan '10

Howard Chu wrote: > masarati(a)aero.polimi.it wrote: >>> * masarati(a)aero.polimi.it [2010-01-24 16:01:23 +0100]: >>>> Funny enough, the same thing is dealt with correctly in certificate >>>> validation/normalization in slapd/schema_init.c >>> That was a result of ITS#5070 (which you filed). >> right :) >> >>> Maybe there is an >>> opportunity for refactoring, but I wouldn't be a good judge of that. >> I don't quite bother about refactoring to minimize code duplication. >> Rather, I think the libldap function x509_cert_get_dn() should first >> validate the certificate, much like slapd's certificateValidate() does. > > Since the cert was obtained thru a TLS handshake, we assume it has already > been validated by the TLS library. Further validation is not needed. What I mean is that the TLS library may handle certificates that our function does not like (as in this case). Slapd's code, while skipping fields, checks their tags. We should do the same here, IMHO. p.

1 0

Re: (ITS#6460) SASL EXTERNAL fails with long certificate serial numbers
by hyc＠symas.com 24 Jan '10

24 Jan '10

masarati(a)aero.polimi.it wrote: >> * masarati(a)aero.polimi.it [2010-01-24 16:01:23 +0100]: >>> Funny enough, the same thing is dealt with correctly in certificate >>> validation/normalization in slapd/schema_init.c >> >> That was a result of ITS#5070 (which you filed). > > right :) > >> Maybe there is an >> opportunity for refactoring, but I wouldn't be a good judge of that. > > I don't quite bother about refactoring to minimize code duplication. > Rather, I think the libldap function x509_cert_get_dn() should first > validate the certificate, much like slapd's certificateValidate() does. Since the cert was obtained thru a TLS handshake, we assume it has already been validated by the TLS library. Further validation is not needed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6461) back-sql quote characters in query
by tolich.arz＠gmail.com 24 Jan '10

24 Jan '10

Full_Name: Anatoly Version: 2.4.19 OS: GNU/Linux URL: Submission from: (NULL) (89.169.85.181) I'm using openldap 2.4.19 with sql backend. I have a troubles with queries that contains single-quote ( ' ) character. For example, if I searching for (cn=Zool'man): <==backsql_srch_query() returns SELECT DISTINCT ldap_entries.id,phpbb_users.user_id,varchar_ci('phpbbUser') AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,phpbb_users WHERE phpbb_users.user_id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND 9=9 AND (varchar_ci(phpbb_users.username)='ZOOL'MAN') Constructed query: SELECT DISTINCT ldap_entries.id,phpbb_users.user_id,varchar_ci('phpbbUser') AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,phpbb_users WHERE phpbb_users.user_id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND 9=9 AND (varchar_ci(phpbb_users.username)='ZOOL'MAN') id: '2' backsql_oc_get_candidates(): error executing query Return code: -1 nativeErrCode=7 SQLengineState=S1000 msg="[unixODBC]ERROR: syntax error at or near "MAN" at character 271; In this case query should be like varchar_ci(phpbb_users.username)='ZOOL\'MAN' instead of 'ZOOL'MAN' Additionally, I fear this opens a possibility of sql injection, depending on RDBMS.

1 0

Re: (ITS#6460) SASL EXTERNAL fails with long certificate serial numbers
by Sergio.Gelato＠astro.su.se 24 Jan '10

24 Jan '10

* masarati(a)aero.polimi.it [2010-01-24 19:14:02 +0100]: > I'm applying the fix, please test. I'm in production with the fix (on 2.4.11; I don't have the time to deploy HEAD right now). syncrepl (which is what I'm using SASL EXTERNAL for) now works again. As for the need to validate the certificate: shouldn't this have been taken care of during the preceding TLS handshake?

1 0

Re: (ITS#6460) SASL EXTERNAL fails with long certificate serial numbers
by masarati＠aero.polimi.it 24 Jan '10

24 Jan '10

> * masarati(a)aero.polimi.it [2010-01-24 16:01:23 +0100]: >> Funny enough, the same thing is dealt with correctly in certificate >> validation/normalization in slapd/schema_init.c > > That was a result of ITS#5070 (which you filed). right :) > Maybe there is an > opportunity for refactoring, but I wouldn't be a good judge of that. I don't quite bother about refactoring to minimize code duplication. Rather, I think the libldap function x509_cert_get_dn() should first validate the certificate, much like slapd's certificateValidate() does. I'm applying the fix, please test. p.

1 0

Re: (ITS#6460) SASL EXTERNAL fails with long certificate serial numbers
by Sergio.Gelato＠astro.su.se 24 Jan '10

24 Jan '10

* masarati(a)aero.polimi.it [2010-01-24 16:01:23 +0100]: > Funny enough, the same thing is dealt with correctly in certificate > validation/normalization in slapd/schema_init.c That was a result of ITS#5070 (which you filed). Maybe there is an opportunity for refactoring, but I wouldn't be a good judge of that.

1 0

Re: (ITS#6460) SASL EXTERNAL fails with long certificate serial numbers
by masarati＠aero.polimi.it 24 Jan '10

24 Jan '10

> Full_Name: Sergio Gelato > Version: 2.4.11 (problem also in HEAD) > OS: Debian GNU/Linux > URL: > Submission from: (NULL) (85.225.123.197) > > > Using (X.509 certificate-based) SASL EXTERNAL authentication fails when > the > serial number of the certificate is longer than 4 octets. > > I have traced the problem to the use, by > libraries/libldap/tls.c:x509_cert_get_dn(), > of ber_get_int() to consume the serial number. This fails when the value > to be > decoded > doesn't fit in a ber_int_t. > > I discovered this bug with Debian's OpenLDAP 2.4.11-1+lenny1 but a look at > the > OpenLDAP CVS indicates that the problem is still present in the current > HEAD > (1.167). > > I've successfully tested the following patch: > ==================================================================================== > RFC5280 §4.1.2.2 says "[c]ertificate users MUST be able to handle > serialNumber > values up to 20 octets". ber_get_int() fails beyond 4 octets. Since we > don't > actually care about the certificate serial number, let's just skip it. > > --- a/libraries/libldap/tls.c > +++ b/libraries/libldap/tls.c > @@ -1673,7 +1673,8 @@ > tag = ber_skip_tag( ber, &len ); /* Context + Constructed (version) */ > if ( tag == 0xa0 ) /* Version is optional */ > tag = ber_get_int( ber, &i ); /* Int: Version */ > - tag = ber_get_int( ber, &i ); /* Int: Serial */ > + tag = ber_skip_tag( ber, &len ); /* *Big* integer: Serial */ > + ber_skip_data( ber, len ); > tag = ber_skip_tag( ber, &len ); /* Sequence: Signature */ > ber_skip_data( ber, len ); > if ( !get_subject ) { Funny enough, the same thing is dealt with correctly in certificate validation/normalization in slapd/schema_init.c p.

1 0

(ITS#6460) SASL EXTERNAL fails with long certificate serial numbers
by Sergio.Gelato＠astro.su.se 23 Jan '10

23 Jan '10

Full_Name: Sergio Gelato Version: 2.4.11 (problem also in HEAD) OS: Debian GNU/Linux URL: Submission from: (NULL) (85.225.123.197) Using (X.509 certificate-based) SASL EXTERNAL authentication fails when the serial number of the certificate is longer than 4 octets. I have traced the problem to the use, by libraries/libldap/tls.c:x509_cert_get_dn(), of ber_get_int() to consume the serial number. This fails when the value to be decoded doesn't fit in a ber_int_t. I discovered this bug with Debian's OpenLDAP 2.4.11-1+lenny1 but a look at the OpenLDAP CVS indicates that the problem is still present in the current HEAD (1.167). I've successfully tested the following patch: ==================================================================================== RFC5280 §4.1.2.2 says "[c]ertificate users MUST be able to handle serialNumber values up to 20 octets". ber_get_int() fails beyond 4 octets. Since we don't actually care about the certificate serial number, let's just skip it. --- a/libraries/libldap/tls.c +++ b/libraries/libldap/tls.c @@ -1673,7 +1673,8 @@ tag = ber_skip_tag( ber, &len ); /* Context + Constructed (version) */ if ( tag == 0xa0 ) /* Version is optional */ tag = ber_get_int( ber, &i ); /* Int: Version */ - tag = ber_get_int( ber, &i ); /* Int: Serial */ + tag = ber_skip_tag( ber, &len ); /* *Big* integer: Serial */ + ber_skip_data( ber, len ); tag = ber_skip_tag( ber, &len ); /* Sequence: Signature */ ber_skip_data( ber, len ); if ( !get_subject ) {

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs