- openldap-bugs - openldap.org

(ITS#6948) slaptest fails a converting a working cn=config from a .conf with a pcache configuration
by tgates81＠gmail.com 23 May '11

23 May '11

Full_Name: Tyler Gates Version: 2.4.25 OS: Ubuntu 10.04 LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (65.184.61.44) I've been fighting with a strange issue related to a backend database using a pcache configuration since upgrading from 2.4.24 to 2.4.25. Assuming there was just something wrong with my cn=config I decided to start back fresh using slapd.conf instead. Once I got the config working just fine I used slaptest to convert the config to a new cn=config. Unfortunately when I tried using -F cn=config instead of my -f slapd.conf, slapd failed with the same old message: May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup: warning, database 0 (hdb) has no suffix May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup_one: starting "(unknown)" May 22 09:15:58 directory-proxy2 slapd[25055]: hdb_db_open: need suffix. May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup_one (type=hdb, suffix="(null)"): bi_db_open failed! (-1) May 22 09:15:58 directory-proxy2 slapd[25055]: slapd shutdown: initiated The backend database has never required me specify a suffix since it is already specified in the ldap overlay and when I try to add it in I get slapd trying to open the database twice which results in the second instance having access issues thus rendering all of the database inaccessible to queries. I'm assuming there has been a configuration change in cn=config for this particular layout but slaptest has not been updated. Below is a copy of the flat file I used that worked fine but failed once converted to cn=config using slaptest -f slapd.conf -F /etc/ldap/slapd.d/ root@directory-proxy:~# grep "^[^#]" /etc/ldap/slapd.conf.back_ldap_ppcache 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/openldap.schema include /etc/ldap/schema/sudo.schema include /etc/ldap/schema/autofs.schema include /etc/ldap/schema/ppolicy.schema include /etc/ldap/schema/qmail.schema include /etc/ldap/schema/puppet.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args modulepath /usr/lib/ldap moduleload back_ldap moduleload back_hdb moduleload pcache moduleload ppolicy TLSCertificateFile /etc/ldap/ssl/slapd.crt TLSCertificateKeyFile /etc/ldap/ssl/slapd.key TLSCACertificateFile /etc/ssl/certs/ca.castlebranch.com.crt loglevel -1 allow bind_anon_dn database config rootdn cn=admin,cn=config rootpw secret access to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break database ldap suffix "dc=domain,dc=com" rootdn "cn=Manager,dc=domain,dc=com" rootpw secret uri "ldaps://directory1.domain.com ldaps://directory2.domain.com" overlay pcache proxycache hdb 100000 3 1000 100 proxyAttrset 0 uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description memberUid uniqueMember objectClass proxyAttrset 1 cn automountInformation proxyAttrset 2 cn mail proxyTemplate (&(objectClass=)(|(memberUid=)(uniqueMember=))) 0 1800 proxyTemplate (&(objectClass=)(uid=)) 0 1800 proxyTemplate (&(objectClass=)(cn=)) 0 1800 proxyTemplate (&(objectClass=)) 0 1800 proxyTemplate (objectClass=) 0 1800 proxyTemplate (&(objectClass=)(memberUid=)) 0 1800 900 proxyTemplate (&(objectClass=)(uniqueMember=)) 0 1800 900 proxyTemplate (&(objectClass=)(uidNumber=)) 0 1800 proxyTemplate (&(objectClass=)(gidNumber=)) 0 1800 proxyTemplate (&(objectClass=)(|(cn=)(gidNumber=))) 1 3600 600 proxyTemplate (&(objectClass=)(|(cn=)(cn=))) 1 3600 600 proxyTemplate (&(objectClass=)(|(cn=)(cn=)(cn=))) 1 3600 600 proxyTemplate (|(cn=)(mail=)(sn=)) 2 7200 directory /var/lib/ldap cachesize 1000 idletimeout 600 idlcachesize 3000 index objectClass eq index cn,mail,surname,givenname eq,subinitial index uidNumber,gidNumber,memberuid,member,uniqueMember eq index uid eq,subinitial index nisMapName,automountInformation eq index userPassword,homeDirectory,loginShell,gecos,description eq index pcacheQueryID eq

1 0

Re: (ITS#6943) segfault in rwmmap in 2.4.25
by Tim.Mooney＠ndsu.edu 20 May '11

20 May '11

In regard to: Re: (ITS#6943) segfault in rwmmap in 2.4.25, masarati(a)aero.po...: > The bug is caused by the fact that "mapping" is always on, and slapo-rwm > checks whether there is anything it can/need to do about special > attributes, and it (incorrectly) assumed attributes have an equality rule. > It has nothing to do with the fact that you defined no rules for search > or so. > > The quick fix would be to check whether sat_equality is NULL; the > (possibly) long fix would be to entirely skip mapping when not needed. My apologies for the delay in responding. I've uploaded a patch, TimMooney-110520.patch to incoming. It tests that sat_equality is not NULL before dereferencing. Is this essentially what you had in mind as a fix? Tim

1 0

Re: (ITS#6944) Add option to limit or remove operation list cache
by quanah＠zimbra.com 20 May '11

20 May '11

--On May 19, 2011 8:03:00 AM +0000 jorge.perez.burgos(a)ericsson.com wrote: > Full_Name: Jorge Perez Burgos > Version: 2.4.21 > OS: SLES 10 SP3 x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.235.15.243) > > > Our slapd uses 256 threads Why do you have 256 thread set? Do you have a 64-core box? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6947) ldapadd crashes with LDIFs with invalid line termination
by jvcelak＠redhat.com 19 May '11

19 May '11

Full_Name: Jan Vcelak Version: 2.4.25 OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-20110519-ldif-countlines.patch Submission from: (NULL) (209.132.186.34) Hello, adding entries to LDAP database from file using ldapadd tool causes memory corruption error, when the last line of the input file is not terminated by '\n' character. The entries are added correctly. All version since 2.4.23 are affected. $ cat >/tmp/input.ldif << EOF > dn: cn=A,dc=my-domain,dc=com > objectClass: inetOrgPerson > objectClass: organizationalPerson > objectClass: person > objectClass: top > cn: A > sn: A > uid: A > mail: A(a)example.com > EOF $ wc -c /tmp/input.ldif 166 /tmp/input.ldif $ truncate -s 165 /tmp/input.ldif $ hexdump -c /tmp/input.ldif 0000000 d n : c n = A , d c = m y - d 0000010 o m a i n , d c = c o m \n o b j 0000020 e c t C l a s s : i n e t O r 0000030 g P e r s o n \n o b j e c t C l 0000040 a s s : o r g a n i z a t i o 0000050 n a l P e r s o n \n o b j e c t 0000060 C l a s s : p e r s o n \n o b 0000070 j e c t C l a s s : t o p \n c 0000080 n : A \n s n : A \n u i d : 0000090 A \n m a i l : A @ e x a m p l 00000a0 e . c o m 00000a5 $ ldapadd -H ldap:// -D cn=Manager,dc=my-domain,dc=com -x -w password -f /tmp/input.ldif adding new entry "cn=A,dc=my-domain,dc=com" *** glibc detected *** ldapadd: free(): invalid pointer: 0x0000000001c435c8 *** ======= Backtrace: ========= /lib64/libc.so.6[0x3626e76d63] ldapadd[0x404505] /lib64/libc.so.6(__libc_start_main+0xfd)[0x3626e1ee5d] ldapadd[0x4037e9] ======= Memory map: ======== ... I am attaching proposed patch, which fixes this issue. Thank you Jan

1 0

(ITS#6946) ldapexop: ber_free_buf: Assertion failed
by jvcelak＠redhat.com 19 May '11

19 May '11

Full_Name: Jan Vcelak Version: 2.4.25 OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-110519-ldapexop-double-free.patch Submission from: (NULL) (209.132.186.34) Hello. A problem with crashing ldapexop was reported to our bugzilla. All versions since 2.4.24 are affected. It seems that the bug was introduced by following change in ldapexop.c. http://www.openldap.org/devel/cvsweb.cgi/clients/tools/ldapexop.c.diff?r1=1… Easy to reproduce. With clean configuration run: $ ldapexop -H ldap:// -x whoami anonymous ldapexop: ../../../libraries/liblber/io.c:186: ber_free_buf: Assertion `((ber)->ber_opts.lbo_valid==0x2)' failed. Aborted Complete steps to reproduce in Fedora are specified in the original bugreport: https://bugzilla.redhat.com/show_bug.cgi?id=699683 I think it is cause by double freeing the result. I am attaching a proposed patch. Please, review my change. Thank you. Jan

1 0

(ITS#6945) nssov does not build on older Linux distributions (RHEL3, RHEL4)
by bgmilne＠staff.telkomsa.net 19 May '11

19 May '11

Full_Name: Buchan Milne Version: 2.4.25 OS: Red Hat Enterprise Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (196.25.124.16) I am aware that these are old, and almost (or already) EOL distributions, but nssov does not build on RHEL3 and RHEL4. On RHEL3, I get: + make -C contrib/slapd-modules/nssov libdir=/usr/lib moduledir=/usr/lib/openldap2.4 make: Entering directory `/home/bgmilne/rpm/BUILD.rh3/openldap-2.4.25/contrib/slapd-modules/nssov' ../../../libtool --mode=compile gcc -g -O2 -I../../../include -I../../../include -I../../../servers/slapd -Inss-pam-ldapd -c alias.c mkdir .libs gcc -g -O2 -I../../../include -I../../../include -I../../../servers/slapd -Inss-pam-ldapd -c alias.c -fPIC -DPIC -o .libs/alias.o In file included from ../../../include/ldap_pvt_thread.h:21, from ../../../servers/slapd/slap.h:57, from nssov.h:43, from alias.c:23: ../../../include/ldap_int_thread.h:69: syntax error before "ldap_int_thread_rdwr_t" ../../../include/ldap_int_thread.h:69: warning: data definition has no type or storage class In file included from ../../../servers/slapd/slap.h:57, from nssov.h:43, from alias.c:23: ../../../include/ldap_pvt_thread.h:36: syntax error before "ldap_pvt_thread_rdwr_t" ../../../include/ldap_pvt_thread.h:36: warning: data definition has no type or storage class ../../../include/ldap_pvt_thread.h:154: syntax error before '*' token ../../../include/ldap_pvt_thread.h:157: syntax error before '*' token ../../../include/ldap_pvt_thread.h:160: syntax error before '*' token ../../../include/ldap_pvt_thread.h:163: syntax error before '*' token ../../../include/ldap_pvt_thread.h:166: syntax error before '*' token ../../../include/ldap_pvt_thread.h:169: syntax error before '*' token ../../../include/ldap_pvt_thread.h:172: syntax error before '*' token ../../../include/ldap_pvt_thread.h:175: syntax error before '*' token ../../../include/ldap_pvt_thread.h:191: syntax error before '*' token ../../../include/ldap_pvt_thread.h:194: syntax error before '*' token ../../../include/ldap_pvt_thread.h:197: syntax error before '*' token make: *** [alias.lo] Error 1 make: Leaving directory `/home/bgmilne/rpm/BUILD.rh3/openldap-2.4.25/contrib/slapd-modules/nssov' ldap_int_thread.h:69 #if defined( HAVE_PTHREAD_RWLOCK_DESTROY ) #define LDAP_THREAD_HAVE_RDWR 1 typedef pthread_rwlock_t ldap_int_thread_rdwr_t; #endif ldap_int_thread.h includes pthread.h, which includes bits/pthreadtypes.h which defines pthread_rwlock_t ... I can't see why this use fails, where the rest of OpenLDAP builds just fine prior to this. smbk5pwd is also affected. I don't have time to investigate further now, but wanted to capture what info I have now.

1 0

Re: (ITS#6943) segfault in rwmmap in 2.4.25
by masarati＠aero.polimi.it 19 May '11

19 May '11

The bug is caused by the fact that "mapping" is always on, and slapo-rwm checks whether there is anything it can/need to do about special attributes, and it (incorrectly) assumed attributes have an equality rule. It has nothing to do with the fact that you defined no rules for search or so. The quick fix would be to check whether sat_equality is NULL; the (possibly) long fix would be to entirely skip mapping when not needed. p.

1 0

(ITS#6944) Add option to limit or remove operation list cache
by jorge.perez.burgos＠ericsson.com 19 May '11

19 May '11

Full_Name: Jorge Perez Burgos Version: 2.4.21 OS: SLES 10 SP3 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.235.15.243) Our slapd uses 256 threads with conn_max_pending_auth 5000. We have seen that with certain network traffic and conditions a huge increased in the amount of memory. After using valgrind and a little study, we have seen slapd cache operation structure in a list. These lists are per thread and could reach high values, in some cases we have seen 12500 operations cached, so 256*12500 could reach around 3GB. It's suggested adding an option to disable this cache or limit the growth of this one for future versions.

1 0

Re: (ITS#6943) segfault in rwmmap in 2.4.25
by Tim.Mooney＠ndsu.edu 18 May '11

18 May '11

In regard to: Re: (ITS#6943) segfault in rwmmap in 2.4.25, masarati(a)aero.po...: >> We don't have any definition for apple-group-nestedgroup in any of the >> schemas that I have loaded. It's not something we support. We're also >> not doing any proxying. Note also that the search base it's using >> (cn=groups,dc=ndsu,dc=nodak,dc=edu) isn't valid. So, it's some Apple >> system on campus that someone has set up to query our LDAP tree, looking >> for things that the Mac OS X expects to find, but that we don't have or >> support. >> >> One thing that confuses me a little -- I set the rwm-rewriteContext to >> "bindDN", which I perhaps incorrectly believed meant that rewriting would >> only be done for authenticated binds (i.e. not anonymous binds), and >> this client did not authenticate. I was under the mistaken impression >> that >> rwm shouldn't even be called in cases like this. I don't (currently) need >> to >> rewrite searches or results from searches, only the bind credentials, for >> when we eventually enable support for ldap authentication. >> >> Does that answer your question? Would it be helpful to see either my >> original slapd.conf or the slapd-config that results from the conversion? > > Yes, either would be useful. Thanks, p. Here it is. Thanks, Tim #@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ #@ #@ TVM: this file is no longer used. All slapd configuration is done via #@ the LDAP/LDIF-based slapd-config(5) backend, using commands like ldapadd, #@ ldapmodify, etc. #@ #@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ # # # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # # TVM: changed all paths from /etc/openldap/schema to # /etc/local/openldap/schema. # TVM: prior slapd.conf files based on earlier distributions of openldap # had fewer default schemas included (the config file we used with 2.3.24 # on RH4 loaded only core, cosine, inetorgperson, misc, and our custom # ndusEduPerson.schema). # For the install on RHEL5, I started with the stock slapd.conf from openldap # 2.4.21 and then removed the ones I didn't think we needed, e.g. corba, # duaconf, dyngroup, java, nis, ppolicy, and collective. # #include /etc/local/openldap/schema/corba.schema include /etc/local/openldap/schema/core.schema include /etc/local/openldap/schema/cosine.schema #include /etc/local/openldap/schema/duaconf.schema #include /etc/local/openldap/schema/dyngroup.schema include /etc/local/openldap/schema/inetorgperson.schema #include /etc/local/openldap/schema/java.schema include /etc/local/openldap/schema/misc.schema #include /etc/local/openldap/schema/nis.schema include /etc/local/openldap/schema/openldap.schema #include /etc/local/openldap/schema/ppolicy.schema #include /etc/local/openldap/schema/collective.schema # # TVM: custom NDUS schema # include /etc/local/openldap/schema/ndusEduPerson.schema # Allow LDAPv2 client connections. This is NOT the default. allow bind_v2 # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args # # TVM: the sizelimit and timelimits we've historically used for slapd # sizelimit 150 timelimit 180 # Load dynamic backend modules: # modulepath /usr/lib/openldap # or /usr/lib64/openldap # moduleload accesslog.la # moduleload auditlog.la # moduleload back_sql.la # moduleload denyop.la # moduleload dyngroup.la # moduleload dynlist.la # moduleload lastmod.la # moduleload pcache.la # moduleload ppolicy.la # moduleload refint.la # moduleload retcode.la # # TVM: uncommented this, we need it for bindDN massaging # moduleload rwm.la # moduleload syncprov.la # moduleload translucent.la # moduleload unique.la # moduleload valsort.la # The next three lines allow use of TLS for encrypting connections using a # dummy test certificate which you can generate by changing to # /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on # slapd.pem so that the ldap user or group can read it. Your client software # may balk at self-signed certificates, however. TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt TLSCertificateFile /etc/pki/tls/certs/ldap.NoDak.edu.crt TLSCertificateKeyFile /etc/pki/tls/certs/ldap.NoDak.edu.key # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # # TVM: FIXME: for testing just require encryption for simple_bind # TVM: this can't be enabled until Dale's code to populate LDAP is ready # for it. #security simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! # # TVM: added NDUS access controls (Note: these were at the bottom of # the older slapd.conf file before, now they're in an earlier section). # # I think we should seriously revisit these # access to filter=(cn=anonymous) attrs=cn,sn by * none # # TVM: inserted this ACL between the two that have been present since # the beginning. This is to try prevent userPassword: from showing up # in ldapsearch output, but still allow it to be used for auth # access to attrs=userPassword by anonymous auth access to * by * read # # TVM: new with our OpenLDAP 2.4.x install: load the rwm overlay # and add rules so that binds with the iid work. # overlay rwm rwm-rewriteEngine on # define a rewriteMap function that returns the dn for a particular attr # This is straight out of the first bindDN example in slapo-rwm(5) rwm-rewriteMap ldap attr2dn "ldap://localhost/dc=nodak,dc=edu?dn?sub" rwm-rewriteContext bindDN # and now the magic: parse out the IID and pass it to the attr2dn function. # This is also almost exactly taken from slapo-rwm(5), though I'm using iid # instead of mail and I'm not anchoring the regex and using $1, so it doesn't # matter if it's qualified or not. rwm-rewriteRule "^(iid=[^, ]+).*" "${attr2dn($1)}" ":@I" ####################################################################### # ldbm and/or bdb database definitions ####################################################################### database hdb suffix "dc=nodak,dc=edu" checkpoint 1024 15 # # TVM: I added these settings as part of the migration to 2.4.x. # These are pure guesses. If memory is still available, we should # probably increase both. Note section 21.4.3 of the guide, that indicates # the idlcachesize should match cachesize when using bdb, but it should # be 3*cachesize for hdb, which doesn't really make a lot # of sense to me, but oh well... See slapd-bdb for more info # cachesize 2048 idlcachesize 6144 # # TVM: using System V shared memory is much faster for recent versions of # the Linux kernel than using mmap(2) files, so we'll give it a try. # # shm_key can be anything, it just identifies a shared memory segment that # BDB can use for its shared memory regions. # shm_key 41 rootdn "cn=Someone Hidden, dc=ndsu, dc=nodak, dc=edu" # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. # rootpw secret # rootpw {crypt}ijFYNcSNctBYg rootpw {SHA}ceHixPjpYAryAobGXZyzztpweto= # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap/data-1 # # Indices to maintain for this database # # TVM: with openldap 2.3.24 on RHEL4 we just commented all of these out and # added our own, some of which exactly duplicated these. I'll keep the first # two index lines and comment out the next three, then supplment with ours. # # Also, previously we maintained a presence (pres) index on *every* one of # these. Section 21.2.3 of the OpenLDAP admin guide makes it very clear # that presence indexing is almost always a bad idea. With that in mind, # I've removed presence indexing from all of these. # index objectClass eq index ou,cn,mail,surname,givenname eq,sub #index uidNumber,gidNumber,loginShell eq #index uid,memberUid eq,sub #index nisMapName,nisMapEntry eq,sub # # TVM: added indexes on all of these. # index mailLocalAddress,mailRoutingAddress,nid eq index iid,uid,services eq,sub index class,college,major eq,sub index group,department,institution,title eq,sub index physicalDeliveryOfficeName,telephoneNumber eq,sub # Replicas of this database #replogfile /var/lib/ldap/openldap-master-replog #replica host=ldap-1.example.com:389 starttls=critical # bindmethod=sasl saslmech=GSSAPI # authcId=host/ldap-master.example.com(a)EXAMPLE.COM # # TVM: this is new with 2.4.x, we'll leave it enabled, see chapter 20 of # the admin guide. # # enable monitoring database monitor rootdn "cn=Someone Hidden, dc=ndsu, dc=nodak, dc=edu" # allow only rootdn to read the monitor access to * by * none

1 0

Re: (ITS#6943) segfault in rwmmap in 2.4.25
by masarati＠aero.polimi.it 18 May '11

18 May '11

> In regard to: Re: (ITS#6943) segfault in rwmmap in 2.4.25, Pierangelo...: > >>> At the time of the search, the very last thing that was logged was >>> >>> May 17 17:03:03 server2 slapd[5168]: conn=28588 op=3 SRCH >>> base="cn=groups,dc=ndsu,dc=nodak,dc=edu" scope=2 deref=0 >>> filter="(&(?objectClass=posixGroup)(?objectClass=apple-group)(objectClass=extensibleObject)(|(?apple-group-nestedgroup=ABCDEFAB-CDEF-ABCD-EFAB-CDEF0000001B)))" >>> >>> May 17 17:03:03 server2 slapd[5168]: conn=28588 op=3 SRCH attr=cn >>> apple-generateduid gidNumber apple-group-realname ttl sambaSID rid >>> primaryGroupID apple-keyword apple-group-nestedgroup >>> >>> >>> I'll happily provide any details that I've mistakenly left out or that >>> would >>> aid >>> in debugging the issue. >>> >>> The issue certainly could be caused by an error in my rwmRewriteRule, >>> but I >>> imagine that slapd shouldn't segfault even if my rwmRewriteRule is >>> wrong. >> >> Yes (I believe), and yes. I believe the mapping is being applied to an >> attribute that is not explicitly defined in the schema, but rather >> proxied or >> somehow treated as undefined. For this reason, the matching rule >> pointer is >> NULL. Can you check the definition of "apple-group-nestedgroup", if >> any? Of >> course, slapo-rwm should not crash on something like this. > > Thank you Pierangelo. > > We don't have any definition for apple-group-nestedgroup in any of the > schemas that I have loaded. It's not something we support. We're also > not doing any proxying. Note also that the search base it's using > (cn=groups,dc=ndsu,dc=nodak,dc=edu) isn't valid. So, it's some Apple > system on campus that someone has set up to query our LDAP tree, looking > for things that the Mac OS X expects to find, but that we don't have or > support. > > One thing that confuses me a little -- I set the rwm-rewriteContext to > "bindDN", which I perhaps incorrectly believed meant that rewriting would > only be done for authenticated binds (i.e. not anonymous binds), and > this client did not authenticate. I was under the mistaken impression > that > rwm shouldn't even be called in cases like this. I don't (currently) need > to > rewrite searches or results from searches, only the bind credentials, for > when we eventually enable support for ldap authentication. > > Does that answer your question? Would it be helpful to see either my > original slapd.conf or the slapd-config that results from the conversion? Yes, either would be useful. Thanks, p.

1 0

Re: (ITS#6943) segfault in rwmmap in 2.4.25
by Tim.Mooney＠ndsu.edu 18 May '11

18 May '11

In regard to: Re: (ITS#6943) segfault in rwmmap in 2.4.25, Pierangelo...: >> At the time of the search, the very last thing that was logged was >> >> May 17 17:03:03 server2 slapd[5168]: conn=28588 op=3 SRCH >> base="cn=groups,dc=ndsu,dc=nodak,dc=edu" scope=2 deref=0 >> filter="(&(?objectClass=posixGroup)(?objectClass=apple-group)(objectClass=extensibleObject)(|(?apple-group-nestedgroup=ABCDEFAB-CDEF-ABCD-EFAB-CDEF0000001B)))" >> >> May 17 17:03:03 server2 slapd[5168]: conn=28588 op=3 SRCH attr=cn >> apple-generateduid gidNumber apple-group-realname ttl sambaSID rid >> primaryGroupID apple-keyword apple-group-nestedgroup >> >> >> I'll happily provide any details that I've mistakenly left out or that would >> aid >> in debugging the issue. >> >> The issue certainly could be caused by an error in my rwmRewriteRule, but I >> imagine that slapd shouldn't segfault even if my rwmRewriteRule is wrong. > > Yes (I believe), and yes. I believe the mapping is being applied to an > attribute that is not explicitly defined in the schema, but rather proxied or > somehow treated as undefined. For this reason, the matching rule pointer is > NULL. Can you check the definition of "apple-group-nestedgroup", if any? Of > course, slapo-rwm should not crash on something like this. Thank you Pierangelo. We don't have any definition for apple-group-nestedgroup in any of the schemas that I have loaded. It's not something we support. We're also not doing any proxying. Note also that the search base it's using (cn=groups,dc=ndsu,dc=nodak,dc=edu) isn't valid. So, it's some Apple system on campus that someone has set up to query our LDAP tree, looking for things that the Mac OS X expects to find, but that we don't have or support. One thing that confuses me a little -- I set the rwm-rewriteContext to "bindDN", which I perhaps incorrectly believed meant that rewriting would only be done for authenticated binds (i.e. not anonymous binds), and this client did not authenticate. I was under the mistaken impression that rwm shouldn't even be called in cases like this. I don't (currently) need to rewrite searches or results from searches, only the bind credentials, for when we eventually enable support for ldap authentication. Does that answer your question? Would it be helpful to see either my original slapd.conf or the slapd-config that results from the conversion? Thanks much, Tim

1 0

Re: (ITS#6943) segfault in rwmmap in 2.4.25
by masarati＠aero.polimi.it 18 May '11

18 May '11

On 05/18/2011 12:42 AM, Tim.Mooney(a)ndsu.edu wrote: > Full_Name: Tim Mooney > Version: 2.4.25 > OS: Linux, RHEL 5.6 x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:4930:106:0:18bb:1140:fa3d:f713) > > > Recently replaced an OpenLDAP 2.3.x server with a newer system running RHEL 5.6 > x86_64. OpenLDAP 2.4.25 + Berkeley DB 4.8.30, built as x86_64 also. We've had > slapd segfault several times now, and the most recent time it happened, I had > slapd running under gdb and caught where it was happening. > > As part of the server and OpenLDAP replacement, we're beginning to support ldap > authentication via SASL pass-through to Kerberos. With the authentication, we > also have the need to do DN rewriting at auth time, which is why I've enabled > rwm and have the following in slapd-config: > > dn: olcOverlay={0}rwm,olcDatabase={-1}frontend,cn=config > objectClass: olcOverlayConfig > objectClass: olcRwmConfig > olcOverlay: {0}rwm > olcRwmRewrite: {0}rwm-rewriteEngine "on" > olcRwmRewrite: {1}rwm-rewriteMap "ldap" "attr2dn" "ldap://localhost/dc=nodak,d > c=edu?dn?sub" > olcRwmRewrite: {2}rwm-rewriteContext "bindDN" > olcRwmRewrite: {3}rwm-rewriteRule "^(iid=[^, ]+).*" "${attr2dn($1)}" ":@I" > olcRwmTFSupport: false > olcRwmNormalizeMapped: FALSE > structuralObjectClass: olcRwmConfig > > > This was generated via the automatic conversion from slapd.conf, the original > entries in slapd.conf were: > > # > # TVM: new with our OpenLDAP 2.4.x install: load the rwm overlay > # and add rules so that binds with the iid work. > # > overlay rwm > rwm-rewriteEngine on > > # define a rewriteMap function that returns the dn for a particular attr > # This is straight out of the first bindDN example in slapo-rwm(5) > rwm-rewriteMap ldap attr2dn "ldap://localhost/dc=nodak,dc=edu?dn?sub" > > rwm-rewriteContext bindDN > # and now the magic: parse out the IID and pass it to the attr2dn function. > # This is also almost exactly taken from slapo-rwm(5), though I'm using iid > # instead of mail and I'm not anchoring the regex and using $1, so it doesn't > # matter if it's qualified or not. > rwm-rewriteRule "^(iid=[^, ]+).*" "${attr2dn($1)}" ":@I" > > > With those rewrite rules in place, certain searches have been triggering the > slapd segfault. > > The segfault: > > [root@server2 ldap]# /etc/init.d/NDUS_ldap stop; gdb /usr/local/sbin/slapd > Stopping slapd: [ OK ] > GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-32.el5_6.2) > Copyright (C) 2009 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later<http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "x86_64-redhat-linux-gnu". > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>... > > warning: no loadable sections found in added symbol-file system-supplied DSO at > 0x2aaaaaf47000 > [Thread debugging using libthread_db enabled] > [New process 5168] > [Thread debugging using libthread_db enabled] > [New Thread 0x40800940 (LWP 5169)] > [New Thread 0x41001940 (LWP 5170)] > [New Thread 0x41802940 (LWP 5182)] > [New Thread 0x42003940 (LWP 5183)] > [New Thread 0x42804940 (LWP 5302)] > [New Thread 0x43005940 (LWP 5303)] > [New Thread 0x43806940 (LWP 7677)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x42804940 (LWP 5302)] > 0x00002aaab0a4e95e in map_attr_value (dc=0x428028a0, adp=0x428026b8, > mapped_attr=0x428026a0, value=0x2aaae10015d0, mapped_value=0x42802690, > remap=0, memctx=0x2aaadbb91740) > at ../../../../servers/slapd/overlays/rwmmap.c:439 > 439 } else if ( ad->ad_type->sat_equality->smr_usage& > SLAP_MR_MUTATION_NORMALIZER ) { > Load new symbol table from "/usr/local/sbin/slapd"? (y or n) y > Reading symbols from /usr/local/sbin/slapd...done. > > (gdb) where > #0 0x00002aaab0a4e95e in map_attr_value (dc=0x428028a0, adp=0x428026b8, > mapped_attr=0x428026a0, value=0x2aaae10015d0, mapped_value=0x42802690, > remap=0, memctx=0x2aaadbb91740) > at ../../../../servers/slapd/overlays/rwmmap.c:439 > #1 0x00002aaab0a4ee87 in rwm_int_filter_map_rewrite (op=0x2aaadbb91380, > dc=0x428028a0, f=0x2aaae1001688, fstr=0x42802730) > at ../../../../servers/slapd/overlays/rwmmap.c:528 > #2 0x00002aaab0a4edba in rwm_int_filter_map_rewrite (op=0x2aaadbb91380, > dc=0x428028a0, f=0x2aaae10016b0, fstr=0x428027d0) > at ../../../../servers/slapd/overlays/rwmmap.c:691 > #3 0x00002aaab0a4edba in rwm_int_filter_map_rewrite (op=0x2aaadbb91380, > dc=0x428028a0, f=0x0, fstr=0x428028c0) > at ../../../../servers/slapd/overlays/rwmmap.c:691 > #4 0x00002aaab0a4f5eb in rwm_filter_map_rewrite (op=0x2aaaaaf29fc0, > dc=0x2aaaaaeab420, f=0x0, fstr=0x2aaaaaf67740) > at ../../../../servers/slapd/overlays/rwmmap.c:793 > #5 0x00002aaab0a4b542 in rwm_op_search (op=0x2aaadbb91380, rs=0x42803c10) > at ../../../../servers/slapd/overlays/rwm.c:969 > #6 0x00002aaaaab5ee0a in overlay_op_walk (op=0x2aaadbb91380, rs=0x42803c10, > which=op_search, oi=0x2aaaab01e060, on=0x2aaaab01e240) > at ../../../servers/slapd/backover.c:659 > #7 0x00002aaaaab5f418 in over_op_func (op=0x2aaadbb91380, rs=0x42803c10, > which=op_search) at ../../../servers/slapd/backover.c:721 > #8 0x00002aaaaaaf7325 in do_search (op=0x2aaadbb91380, rs=0x42803c10) > at ../../../servers/slapd/search.c:217 > #9 0x00002aaaaaaf4644 in connection_operation (ctx=0x42803d60, > arg_v=<value optimized out>) at ../../../servers/slapd/connection.c:1113 > #10 0x00002aaaaaaf4ca1 in connection_read_thread (ctx=0x42803d60, > argv=<value optimized out>) at ../../../servers/slapd/connection.c:1249 > #11 0x00002aaaaabf3d08 in ldap_int_thread_pool_wrapper (xpool=0x2aaaaaf7dfa0) > at ../../../libraries/libldap_r/tpool.c:685 > #12 0x00002aaaad5b973d in start_thread () from /lib64/libpthread.so.0 > #13 0x00002aaaadaac0cd in clone () from /lib64/libc.so.6 > (gdb) print dc > $1 = (dncookie *) 0x428028a0 > (gdb) print *dc > $2 = {rwmap = 0x2aaaab01e420, conn = 0x2aaab0c70330, > ctx = 0x2aaab0a50519 "searchFilterAttrDN", rs = 0x42803c10} > (gdb) print dc->rwmap > $3 = (struct ldaprwmap *) 0x2aaaab01e420 > (gdb) print *(dc->rwmap) > $4 = {rwm_rw = 0x2aaaab01e480, rwm_bva_rewrite = 0x2aaaab023a50, rwm_oc = { > drop_missing = 0, map = 0x0, remap = 0x0}, rwm_at = {drop_missing = 0, > map = 0x0, remap = 0x0}, rwm_bva_map = 0x0, rwm_flags = 2} > > (gdb) print adp > $5 = (AttributeDescription **) 0x428026b8 > (gdb) print *adp > $6 = (AttributeDescription *) 0x2aaae10015f0 > (gdb) print **adp > $7 = {ad_next = 0x7564652e6b61646f, ad_type = 0x2aaaaaeab420, ad_cname = { > bv_len = 23, bv_val = 0x2aaae1001628 "apple-group-nestedgroup"}, > ad_tags = {bv_len = 145, bv_val = 0x91<Address 0x91 out of bounds>}, > ad_flags = 4096} > (gdb) print ad->ad_type->sat_equality->smr_usage > Cannot access memory at address 0x58 > > > > (gdb) print ad->ad_type->sat_equality > $8 = (MatchingRule *) 0x0 > > (gdb) print *(ad->ad_type) > $10 = {sat_atype = {at_oid = 0x2aaaaac38a54 "1.1.1", at_names = 0x0, > at_desc = 0x2aaaaac35d10 "Catchall for undefined attribute types", > at_obsolete = 1, at_sup_oid = 0x0, at_equality_oid = 0x0, > at_ordering_oid = 0x0, at_substr_oid = 0x0, at_syntax_oid = 0x0, > at_syntax_len = 0, at_single_value = 0, at_collective = 0, > at_no_user_mod = 1, at_usage = 3, at_extensions = 0x0}, sat_cname = { > bv_len = 9, bv_val = 0x2aaaaac38a5a "UNDEFINED"}, sat_sup = 0x0, > sat_subtypes = 0x0, sat_equality = 0x0, sat_approx = 0x0, > sat_ordering = 0x0, sat_substr = 0x0, sat_syntax = 0x2aaaaaf694e0, > sat_check = 0, sat_oidmacro = 0x0, sat_soidmacro = 0x0, sat_flags = 768, > sat_next = {stqe_next = 0x0}, sat_ad = 0x0, sat_ad_mutex = {__data = { > __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, > __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, > __size = '\000'<repeats 39 times>, __align = 0}} > (gdb) print value > $11 = (struct berval *) 0x2aaae10015d0 > (gdb) print *value > $12 = {bv_len = 36, > bv_val = 0x2aaae1001650 "ABCDEFAB-CDEF-ABCD-EFAB-CDEF0000001B"} > (gdb) print *mapped_value > $13 = {bv_len = 0, bv_val = 0x2aaae10015a0 "\243"} > (gdb) print *mapped_attr > $14 = {bv_len = 23, bv_val = 0x2aaae1001628 "apple-group-nestedgroup"} > > > At the time of the search, the very last thing that was logged was > > May 17 17:03:03 server2 slapd[5168]: conn=28588 op=3 SRCH > base="cn=groups,dc=ndsu,dc=nodak,dc=edu" scope=2 deref=0 > filter="(&(?objectClass=posixGroup)(?objectClass=apple-group)(objectClass=extensibleObject)(|(?apple-group-nestedgroup=ABCDEFAB-CDEF-ABCD-EFAB-CDEF0000001B)))" > > May 17 17:03:03 server2 slapd[5168]: conn=28588 op=3 SRCH attr=cn > apple-generateduid gidNumber apple-group-realname ttl sambaSID rid > primaryGroupID apple-keyword apple-group-nestedgroup > > > I'll happily provide any details that I've mistakenly left out or that would aid > in debugging the issue. > > The issue certainly could be caused by an error in my rwmRewriteRule, but I > imagine that slapd shouldn't segfault even if my rwmRewriteRule is wrong. Yes (I believe), and yes. I believe the mapping is being applied to an attribute that is not explicitly defined in the schema, but rather proxied or somehow treated as undefined. For this reason, the matching rule pointer is NULL. Can you check the definition of "apple-group-nestedgroup", if any? Of course, slapo-rwm should not crash on something like this. p.

1 0

(ITS#6943) segfault in rwmmap in 2.4.25
by Tim.Mooney＠ndsu.edu 18 May '11

18 May '11

Full_Name: Tim Mooney Version: 2.4.25 OS: Linux, RHEL 5.6 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:4930:106:0:18bb:1140:fa3d:f713) Recently replaced an OpenLDAP 2.3.x server with a newer system running RHEL 5.6 x86_64. OpenLDAP 2.4.25 + Berkeley DB 4.8.30, built as x86_64 also. We've had slapd segfault several times now, and the most recent time it happened, I had slapd running under gdb and caught where it was happening. As part of the server and OpenLDAP replacement, we're beginning to support ldap authentication via SASL pass-through to Kerberos. With the authentication, we also have the need to do DN rewriting at auth time, which is why I've enabled rwm and have the following in slapd-config: dn: olcOverlay={0}rwm,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: {0}rwm olcRwmRewrite: {0}rwm-rewriteEngine "on" olcRwmRewrite: {1}rwm-rewriteMap "ldap" "attr2dn" "ldap://localhost/dc=nodak,d c=edu?dn?sub" olcRwmRewrite: {2}rwm-rewriteContext "bindDN" olcRwmRewrite: {3}rwm-rewriteRule "^(iid=[^, ]+).*" "${attr2dn($1)}" ":@I" olcRwmTFSupport: false olcRwmNormalizeMapped: FALSE structuralObjectClass: olcRwmConfig This was generated via the automatic conversion from slapd.conf, the original entries in slapd.conf were: # # TVM: new with our OpenLDAP 2.4.x install: load the rwm overlay # and add rules so that binds with the iid work. # overlay rwm rwm-rewriteEngine on # define a rewriteMap function that returns the dn for a particular attr # This is straight out of the first bindDN example in slapo-rwm(5) rwm-rewriteMap ldap attr2dn "ldap://localhost/dc=nodak,dc=edu?dn?sub" rwm-rewriteContext bindDN # and now the magic: parse out the IID and pass it to the attr2dn function. # This is also almost exactly taken from slapo-rwm(5), though I'm using iid # instead of mail and I'm not anchoring the regex and using $1, so it doesn't # matter if it's qualified or not. rwm-rewriteRule "^(iid=[^, ]+).*" "${attr2dn($1)}" ":@I" With those rewrite rules in place, certain searches have been triggering the slapd segfault. The segfault: [root@server2 ldap]# /etc/init.d/NDUS_ldap stop; gdb /usr/local/sbin/slapd Stopping slapd: [ OK ] GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-32.el5_6.2) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... warning: no loadable sections found in added symbol-file system-supplied DSO at 0x2aaaaaf47000 [Thread debugging using libthread_db enabled] [New process 5168] [Thread debugging using libthread_db enabled] [New Thread 0x40800940 (LWP 5169)] [New Thread 0x41001940 (LWP 5170)] [New Thread 0x41802940 (LWP 5182)] [New Thread 0x42003940 (LWP 5183)] [New Thread 0x42804940 (LWP 5302)] [New Thread 0x43005940 (LWP 5303)] [New Thread 0x43806940 (LWP 7677)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x42804940 (LWP 5302)] 0x00002aaab0a4e95e in map_attr_value (dc=0x428028a0, adp=0x428026b8, mapped_attr=0x428026a0, value=0x2aaae10015d0, mapped_value=0x42802690, remap=0, memctx=0x2aaadbb91740) at ../../../../servers/slapd/overlays/rwmmap.c:439 439 } else if ( ad->ad_type->sat_equality->smr_usage & SLAP_MR_MUTATION_NORMALIZER ) { Load new symbol table from "/usr/local/sbin/slapd"? (y or n) y Reading symbols from /usr/local/sbin/slapd...done. (gdb) where #0 0x00002aaab0a4e95e in map_attr_value (dc=0x428028a0, adp=0x428026b8, mapped_attr=0x428026a0, value=0x2aaae10015d0, mapped_value=0x42802690, remap=0, memctx=0x2aaadbb91740) at ../../../../servers/slapd/overlays/rwmmap.c:439 #1 0x00002aaab0a4ee87 in rwm_int_filter_map_rewrite (op=0x2aaadbb91380, dc=0x428028a0, f=0x2aaae1001688, fstr=0x42802730) at ../../../../servers/slapd/overlays/rwmmap.c:528 #2 0x00002aaab0a4edba in rwm_int_filter_map_rewrite (op=0x2aaadbb91380, dc=0x428028a0, f=0x2aaae10016b0, fstr=0x428027d0) at ../../../../servers/slapd/overlays/rwmmap.c:691 #3 0x00002aaab0a4edba in rwm_int_filter_map_rewrite (op=0x2aaadbb91380, dc=0x428028a0, f=0x0, fstr=0x428028c0) at ../../../../servers/slapd/overlays/rwmmap.c:691 #4 0x00002aaab0a4f5eb in rwm_filter_map_rewrite (op=0x2aaaaaf29fc0, dc=0x2aaaaaeab420, f=0x0, fstr=0x2aaaaaf67740) at ../../../../servers/slapd/overlays/rwmmap.c:793 #5 0x00002aaab0a4b542 in rwm_op_search (op=0x2aaadbb91380, rs=0x42803c10) at ../../../../servers/slapd/overlays/rwm.c:969 #6 0x00002aaaaab5ee0a in overlay_op_walk (op=0x2aaadbb91380, rs=0x42803c10, which=op_search, oi=0x2aaaab01e060, on=0x2aaaab01e240) at ../../../servers/slapd/backover.c:659 #7 0x00002aaaaab5f418 in over_op_func (op=0x2aaadbb91380, rs=0x42803c10, which=op_search) at ../../../servers/slapd/backover.c:721 #8 0x00002aaaaaaf7325 in do_search (op=0x2aaadbb91380, rs=0x42803c10) at ../../../servers/slapd/search.c:217 #9 0x00002aaaaaaf4644 in connection_operation (ctx=0x42803d60, arg_v=<value optimized out>) at ../../../servers/slapd/connection.c:1113 #10 0x00002aaaaaaf4ca1 in connection_read_thread (ctx=0x42803d60, argv=<value optimized out>) at ../../../servers/slapd/connection.c:1249 #11 0x00002aaaaabf3d08 in ldap_int_thread_pool_wrapper (xpool=0x2aaaaaf7dfa0) at ../../../libraries/libldap_r/tpool.c:685 #12 0x00002aaaad5b973d in start_thread () from /lib64/libpthread.so.0 #13 0x00002aaaadaac0cd in clone () from /lib64/libc.so.6 (gdb) print dc $1 = (dncookie *) 0x428028a0 (gdb) print *dc $2 = {rwmap = 0x2aaaab01e420, conn = 0x2aaab0c70330, ctx = 0x2aaab0a50519 "searchFilterAttrDN", rs = 0x42803c10} (gdb) print dc->rwmap $3 = (struct ldaprwmap *) 0x2aaaab01e420 (gdb) print *(dc->rwmap) $4 = {rwm_rw = 0x2aaaab01e480, rwm_bva_rewrite = 0x2aaaab023a50, rwm_oc = { drop_missing = 0, map = 0x0, remap = 0x0}, rwm_at = {drop_missing = 0, map = 0x0, remap = 0x0}, rwm_bva_map = 0x0, rwm_flags = 2} (gdb) print adp $5 = (AttributeDescription **) 0x428026b8 (gdb) print *adp $6 = (AttributeDescription *) 0x2aaae10015f0 (gdb) print **adp $7 = {ad_next = 0x7564652e6b61646f, ad_type = 0x2aaaaaeab420, ad_cname = { bv_len = 23, bv_val = 0x2aaae1001628 "apple-group-nestedgroup"}, ad_tags = {bv_len = 145, bv_val = 0x91 <Address 0x91 out of bounds>}, ad_flags = 4096} (gdb) print ad->ad_type->sat_equality->smr_usage Cannot access memory at address 0x58 (gdb) print ad->ad_type->sat_equality $8 = (MatchingRule *) 0x0 (gdb) print *(ad->ad_type) $10 = {sat_atype = {at_oid = 0x2aaaaac38a54 "1.1.1", at_names = 0x0, at_desc = 0x2aaaaac35d10 "Catchall for undefined attribute types", at_obsolete = 1, at_sup_oid = 0x0, at_equality_oid = 0x0, at_ordering_oid = 0x0, at_substr_oid = 0x0, at_syntax_oid = 0x0, at_syntax_len = 0, at_single_value = 0, at_collective = 0, at_no_user_mod = 1, at_usage = 3, at_extensions = 0x0}, sat_cname = { bv_len = 9, bv_val = 0x2aaaaac38a5a "UNDEFINED"}, sat_sup = 0x0, sat_subtypes = 0x0, sat_equality = 0x0, sat_approx = 0x0, sat_ordering = 0x0, sat_substr = 0x0, sat_syntax = 0x2aaaaaf694e0, sat_check = 0, sat_oidmacro = 0x0, sat_soidmacro = 0x0, sat_flags = 768, sat_next = {stqe_next = 0x0}, sat_ad = 0x0, sat_ad_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}} (gdb) print value $11 = (struct berval *) 0x2aaae10015d0 (gdb) print *value $12 = {bv_len = 36, bv_val = 0x2aaae1001650 "ABCDEFAB-CDEF-ABCD-EFAB-CDEF0000001B"} (gdb) print *mapped_value $13 = {bv_len = 0, bv_val = 0x2aaae10015a0 "\243"} (gdb) print *mapped_attr $14 = {bv_len = 23, bv_val = 0x2aaae1001628 "apple-group-nestedgroup"} At the time of the search, the very last thing that was logged was May 17 17:03:03 server2 slapd[5168]: conn=28588 op=3 SRCH base="cn=groups,dc=ndsu,dc=nodak,dc=edu" scope=2 deref=0 filter="(&(?objectClass=posixGroup)(?objectClass=apple-group)(objectClass=extensibleObject)(|(?apple-group-nestedgroup=ABCDEFAB-CDEF-ABCD-EFAB-CDEF0000001B)))" May 17 17:03:03 server2 slapd[5168]: conn=28588 op=3 SRCH attr=cn apple-generateduid gidNumber apple-group-realname ttl sambaSID rid primaryGroupID apple-keyword apple-group-nestedgroup I'll happily provide any details that I've mistakenly left out or that would aid in debugging the issue. The issue certainly could be caused by an error in my rwmRewriteRule, but I imagine that slapd shouldn't segfault even if my rwmRewriteRule is wrong.

1 0

(ITS#6942) updateref config is inadequate
by hyc＠OpenLDAP.org 12 May '11

12 May '11

Full_Name: Howard Chu Version: 2.4.x OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc This was pointed out on the mailing list, I've lost the exact message now. We allow multiple consumers in a single DB, but we only allow a single updateref on the DB. This is clearly broken; we need to be able to specify an updateref per consumer. This also ties in with other discussions about moving updateref processing out of the frontend. Doing it in the frontend was OK back in OpenLDAP 2.3 and earlier, but not any more.

1 0

(ITS#6941
by tjgates＠castlebranch.com 12 May '11

12 May '11

------=_Part_26721_267475779.1305154501363 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Some how this got duplicated from ITS#6940, please close. -- Tyler Gates Systems Administrator Castle Branch Inc. 910-815-3880 ext 7230 tjgates(a)castlebranch.com This e-mail message, including any attachments, may contain private, confidential, and privileged information for the restricted use of the intended recipient(s). If you are not the intended recipient(s), you may NOT use, disclose, copy, or disseminate this information. Please notify the sender by return e-mail of this misdirected correspondence and destroy all copies of the original message including all attachments. Your cooperation is appreciated. ------=_Part_26721_267475779.1305154501363 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Arial; font-size: 12pt; color: #000000'><span>Some how this got duplicated from ITS#6940, please close.<br><br>-- <br><br>Tyler Gates<br>Systems Administrator<br>Castle Branch Inc.<br>910-815-3880 ext 7230<br>tjgates(a)castlebranch.com<br><br>This e-mail message, including any attachments, may contain private,<br>confidential, and privileged information for the restricted use of the<br>intended recipient(s). If you are not the intended recipient(s), you<br>may NOT use, disclose, copy, or disseminate this information. Please<br>notify the sender by return e-mail of this misdirected correspondence<br>and destroy all copies of the original message including all attachments.<br>Your cooperation is appreciated.<br></span></div></body></html> ------=_Part_26721_267475779.1305154501363--

1 0

(ITS#6941) issues reading the db directory since 2.4.25
by tjgates＠castlebranch.com 11 May '11

11 May '11

Full_Name: Tyler Gates Version: 2.4.25 OS: Ubuntu 10.04.2 LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.106.216.17) Ever since updating to OpenLDAP 2.4.25, I've been experiencing what seems to be read issues on the directory database. I get non-responsive queries and messages complaining about DB_CONFIG not being found even though these files are obviously being created by slapd without issues during startup: root@directory-proxy2:/var/lib/ldap# rm -rf /var/lib/ldap/* root@directory-proxy2:/var/lib/ldap# ls -la /var/lib/ldap/ total 8 drwxr-x--- 2 openldap openldap 4096 2011-05-11 09:28 . drwxr-xr-x 44 root root 4096 2011-03-25 12:47 .. root@directory-proxy2:/var/lib/ldap# service slapd start * Starting OpenLDAP slapd ...done. root@directory-proxy2:/var/lib/ldap# ls -la /var/lib/ldap/ total 10380 drwxr-x--- 2 openldap openldap 4096 2011-05-11 09:28 . drwxr-xr-x 44 root root 4096 2011-03-25 12:47 .. -rw-r--r-- 1 openldap openldap 4096 2011-05-11 09:28 alock -rw------- 1 openldap openldap 24576 2011-05-11 09:28 __db.001 -rw------- 1 openldap openldap 843776 2011-05-11 09:28 __db.002 -rw------- 1 openldap openldap 13115392 2011-05-11 09:28 __db.003 -rw------- 1 openldap openldap 2359296 2011-05-11 09:28 __db.004 -rw------- 1 openldap openldap 540672 2011-05-11 09:28 __db.005 -rw------- 1 openldap openldap 32768 2011-05-11 09:28 __db.006 -rw-r--r-- 1 openldap openldap 120 2011-05-11 09:28 DB_CONFIG -rw------- 1 openldap openldap 8192 2011-05-11 09:28 dn2id.bdb -rw------- 1 openldap openldap 32768 2011-05-11 09:28 id2entry.bdb -rw------- 1 openldap openldap 10485760 2011-05-11 09:28 log.0000000001 root@directory-proxy2:/var/lib/ldap# tail -n100 /var/log/slapd.log |grep DB_CONFIG May 11 09:28:34 directory-proxy2 slapd[7266]: hdb_db_open: warning - no DB_CONFIG file found in directory /var/lib/ldap: (14).#012Expect poor performance for suffix "dc=castlebranch,dc=com". Fine. So now that DB_CONFIG obviously exists, I restart slapd: root@directory-proxy2:/var/lib/ldap# service slapd restart * Stopping OpenLDAP slapd ...done. * Starting OpenLDAP slapd ...done. root@directory-proxy2:/var/lib/ldap# ls -la /var/lib/ldap/ total 10380 drwxr-x--- 2 openldap openldap 4096 2011-05-11 09:30 . drwxr-xr-x 44 root root 4096 2011-03-25 12:47 .. -rw-r--r-- 1 openldap openldap 4096 2011-05-11 09:30 alock -rw------- 1 openldap openldap 24576 2011-05-11 09:30 __db.001 -rw------- 1 openldap openldap 843776 2011-05-11 09:30 __db.002 -rw------- 1 openldap openldap 13115392 2011-05-11 09:30 __db.003 -rw------- 1 openldap openldap 2359296 2011-05-11 09:30 __db.004 -rw------- 1 openldap openldap 540672 2011-05-11 09:30 __db.005 -rw------- 1 openldap openldap 32768 2011-05-11 09:30 __db.006 -rw-r--r-- 1 openldap openldap 120 2011-05-11 09:28 DB_CONFIG -rw------- 1 openldap openldap 8192 2011-05-11 09:28 dn2id.bdb -rw------- 1 openldap openldap 32768 2011-05-11 09:28 id2entry.bdb -rw------- 1 openldap openldap 10485760 2011-05-11 09:30 log.0000000001 root@directory-proxy2:/var/lib/ldap# tail -n100 /var/log/slapd.log |grep DB_CONFIG May 11 09:30:08 directory-proxy2 slapd[7297]: hdb_db_open: warning - no DB_CONFIG file found in directory /var/lib/ldap: (14).#012Expect poor performance for suffix "dc=castlebranch,dc=com". As you can it still complains that DB_CONFIG does not exist when it obviously does and is owned correctly: root@directory-proxy2:/var/lib/ldap# ps aux |grep slapd openldap 7297 0.0 0.5 56248 5928 ? Ssl 09:30 0:00 /usr/sbin/slapd -h ldap:/// ldapi:/// ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d Any help would be appreciated.

1 0

(ITS#6940) issues reading the db directory since 2.4.25
by tjgates＠castlebranch.com 11 May '11

11 May '11

Full_Name: Tyler Gates Version: 2.4.25 OS: Ubuntu 10.04.2 LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.106.216.17) Ever since updating to OpenLDAP 2.4.25, I've been experiencing what seems to be read issues on the directory database. I get non-responsive queries and messages complaining about DB_CONFIG not being found even though these files are obviously being created by slapd without issues during startup: root@directory-proxy2:/var/lib/ldap# rm -rf /var/lib/ldap/* root@directory-proxy2:/var/lib/ldap# ls -la /var/lib/ldap/ total 8 drwxr-x--- 2 openldap openldap 4096 2011-05-11 09:28 . drwxr-xr-x 44 root root 4096 2011-03-25 12:47 .. root@directory-proxy2:/var/lib/ldap# service slapd start * Starting OpenLDAP slapd ...done. root@directory-proxy2:/var/lib/ldap# ls -la /var/lib/ldap/ total 10380 drwxr-x--- 2 openldap openldap 4096 2011-05-11 09:28 . drwxr-xr-x 44 root root 4096 2011-03-25 12:47 .. -rw-r--r-- 1 openldap openldap 4096 2011-05-11 09:28 alock -rw------- 1 openldap openldap 24576 2011-05-11 09:28 __db.001 -rw------- 1 openldap openldap 843776 2011-05-11 09:28 __db.002 -rw------- 1 openldap openldap 13115392 2011-05-11 09:28 __db.003 -rw------- 1 openldap openldap 2359296 2011-05-11 09:28 __db.004 -rw------- 1 openldap openldap 540672 2011-05-11 09:28 __db.005 -rw------- 1 openldap openldap 32768 2011-05-11 09:28 __db.006 -rw-r--r-- 1 openldap openldap 120 2011-05-11 09:28 DB_CONFIG -rw------- 1 openldap openldap 8192 2011-05-11 09:28 dn2id.bdb -rw------- 1 openldap openldap 32768 2011-05-11 09:28 id2entry.bdb -rw------- 1 openldap openldap 10485760 2011-05-11 09:28 log.0000000001 root@directory-proxy2:/var/lib/ldap# tail -n100 /var/log/slapd.log |grep DB_CONFIG May 11 09:28:34 directory-proxy2 slapd[7266]: hdb_db_open: warning - no DB_CONFIG file found in directory /var/lib/ldap: (14).#012Expect poor performance for suffix "dc=castlebranch,dc=com". Fine. So now that DB_CONFIG obviously exists, I restart slapd: root@directory-proxy2:/var/lib/ldap# service slapd restart * Stopping OpenLDAP slapd ...done. * Starting OpenLDAP slapd ...done. root@directory-proxy2:/var/lib/ldap# ls -la /var/lib/ldap/ total 10380 drwxr-x--- 2 openldap openldap 4096 2011-05-11 09:30 . drwxr-xr-x 44 root root 4096 2011-03-25 12:47 .. -rw-r--r-- 1 openldap openldap 4096 2011-05-11 09:30 alock -rw------- 1 openldap openldap 24576 2011-05-11 09:30 __db.001 -rw------- 1 openldap openldap 843776 2011-05-11 09:30 __db.002 -rw------- 1 openldap openldap 13115392 2011-05-11 09:30 __db.003 -rw------- 1 openldap openldap 2359296 2011-05-11 09:30 __db.004 -rw------- 1 openldap openldap 540672 2011-05-11 09:30 __db.005 -rw------- 1 openldap openldap 32768 2011-05-11 09:30 __db.006 -rw-r--r-- 1 openldap openldap 120 2011-05-11 09:28 DB_CONFIG -rw------- 1 openldap openldap 8192 2011-05-11 09:28 dn2id.bdb -rw------- 1 openldap openldap 32768 2011-05-11 09:28 id2entry.bdb -rw------- 1 openldap openldap 10485760 2011-05-11 09:30 log.0000000001 root@directory-proxy2:/var/lib/ldap# tail -n100 /var/log/slapd.log |grep DB_CONFIG May 11 09:30:08 directory-proxy2 slapd[7297]: hdb_db_open: warning - no DB_CONFIG file found in directory /var/lib/ldap: (14).#012Expect poor performance for suffix "dc=castlebranch,dc=com". As you can it still complains that DB_CONFIG does not exist when it obviously does and is owned correctly: root@directory-proxy2:/var/lib/ldap# ps aux |grep slapd openldap 7297 0.0 0.5 56248 5928 ? Ssl 09:30 0:00 /usr/sbin/slapd -h ldap:/// ldapi:/// ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d Any help would be appreciated.

1 0

(ITS#6939) slapd double free corruption with olcTlsCipherSuite and GnuTLS
by quanah＠OpenLDAP.org 11 May '11

11 May '11

Full_Name: Quanah Gibson-Mount Version: 2.4.25 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) *** glibc detected *** slapd: double free or corruption (top): 0x08894138 *** and slapd crashes with an abort signal. this happens when i set "olcTLSCipherSuite: ___" doesn't matter what, it crashes. doesn't happen with openssl-built slapd, but only with gnutls-built one.

1 0

(ITS#6938) Windows IPv6 support
by kurt＠OpenLDAP.org 11 May '11

11 May '11

Full_Name: Kurt Zeilenga Version: all OS: Windows7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.3.217.253) Feature request: extend Windows port to support IPv6

1 0

(ITS#6937) Remove --enable-proctitle and strdup(optarg)
by h.b.furuseth＠usit.uio.no 10 May '11

10 May '11

Full_Name: Hallvard B Furuseth Version: master, 2.4.25 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard "configure --enable-proctitle" uses setproctitle/proctitle(), which we no longer use. So I'll remove that and liblutil/setproctitle.c. That's the default implementation, which works by overwriting argv[]. That's got to be why we have strdup(optarg) instead of just optarg all over the place. So we can drop the strdup()s, which gets rid some admittedly unimportant memory leak reports from program checkers.

1 0

Re: (ITS#6897) segfault in lber on close
by h.b.furuseth＠usit.uio.no 09 May '11

09 May '11

tarbuck(a)futurewest.ca writes: > backtrace shows what looks to be a double free() call from lber. > This is a production system, so I don't have a whole lot of > information (fixing was the priority). Well, can you show that backtrace? Otherwise there's no chance at all of investigating this further. slapd uses liblber for a lot of its allocations, so the double free could come from just about anywhere. -- Hallvard

1 0

(ITS#6935) Uninitialized variables with certificates
by h.b.furuseth＠usit.uio.no 09 May '11

09 May '11

Full_Name: Hallvard B Furuseth Version: master, 2.4.25 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) serialNumberAndIssuerNormalize() failure can free uninitialized variable s3. attributeCertificateExactNormalize() failure can free uninitialized variables sn2 and i_sn2. Klocwork issues #442-444. Fixing.

1 0

(ITS#6934) the typos in the man page slapo-nssov.5
by sergei＠bslos.com 09 May '11

09 May '11

Full_Name: Sergei Butakov Version: 2.4.25 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (94.190.117.137) There are the typos in the man page contrib/slapd-modules/nssov/slapo-nssov.5 - in the string #216 instead of 'nssov-pam-minuid' must be 'nssov-pam-min-uid' and in the string #221 instead of 'nssov-pam-maxuid' must be 'nssov-pam-max-uid'.

1 0

(ITS#6933) Broken NT Service ConfigFile param
by h.b.furuseth＠usit.uio.no 09 May '11

09 May '11

Full_Name: Hallvard B Furuseth Version: master, 2.4.24 OS: Windows NT + what else? URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) slapd/main.c does #ifdef HAVE_NT_SERVICE_MANAGER newConfigFile = (char*)lutil_getRegParam( regService, "ConfigFile" ); newConfigDir = (char*)lutil_getRegParam( regService, "ConfigDir" ); but does not strdup() newConfigFile even though lutil_getRegParam returns static memory. Thus ConfigDir can overwrite ConfigFile. Don't know if that only happens if both are set, since I do not know NT. Fixing: Adding the strdup()s. Which OSes does this apply to? Only Windows NT, or more than that the same way as #ifdef _WIN32 also tests for newer Windowses?

1 0

Re: (ITS#6641) Syncrepl failure with 'overlay unique'
by ondrej.kuznik＠acision.com 06 May '11

06 May '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/21/2011 04:11 AM, hyc(a)symas.com wrote: > ondrej.kuznik(a)acision.com wrote: >> After a conversation with Howard, I have modified the patches so that >> the overlay check for the ManageDsaIt control instead. That control >> should be set for each operation coming from replication. The patches >> are here: >> ftp://ftp.openldap.org/incoming/ondrej-kuznik-20101202-unique_bypass_v2.tgz >> >> Is there anything else that comes to mind? > > I'm not sure it merits a config keyword. We already have instances where > administrators are implicitly allowed to bypass rules that restrict normal > users, and replication is obviously a system-level operation, not user level. > Rereading the discussions makes me agree with you. I have prepared a patch without the config keyword and modified the slapo-unique manpage accordingly. ftp://ftp.openldap.org/incoming/ondrej-kuznik-20110506-unique_bypass_v3.tgz Again the IPR notice: The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2010 Acision Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. - -- Ondrej Kuznik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3D6ZkACgkQ9GWxeeH+cXtv7ACgl+6zPsyecGdWxjEnDL2CPDDp 2HoAoJ3D1XcuAJ1d+L/kwLLBltbo/ifo =RyJh -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs