openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs