- openldap-bugs - openldap.org

(ITS#6951) pcache: valgrind reports some errors when bind-caching is enabled
by ralf＠OpenLDAP.org 24 May '11

24 May '11

Full_Name: Ralf Haferkamp Version: 2.4.25/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.222.177) Submitted by: ralf I get this when starting a bind-caching slapo-pcache setup under valgrind: ==18290== Invalid write of size 1 ==18290== at 0x59628F: ftemp_attrs (pcache.c:490) ==18290== by 0x5A29E0: pc_cf_gen (pcache.c:4199) [..] ==18290== Address 0x768dcc6 is 0 bytes after a block of size 6 alloc'd ==18290== at 0x4C2683D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==18290== by 0x509CC85: ber_memalloc_x (memory.c:228) ==18290== by 0x46B958: ch_malloc (ch_malloc.c:54) ==18290== by 0x596206: ftemp_attrs (pcache.c:448) [..] ==18290== ==18290== Invalid write of size 1 ==18290== at 0x5A3153: pc_cf_gen (pcache.c:4281) [..] ==18290== Address 0x768e437 is 0 bytes after a block of size 7 alloc'd ==18290== at 0x4C2683D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==18290== by 0x509CC85: ber_memalloc_x (memory.c:228) ==18290== by 0x46B958: ch_malloc (ch_malloc.c:54) ==18290== by 0x5A30D5: pc_cf_gen (pcache.c:4270) [..] A fix is on the way to HEAD.

1 0

Re: (ITS#6920) OpenLDAP 2.4.25 / Berkeley DB 4.8.30 Solaris 10 x86 slapd hangs
by fumiyas＠osstech.jp 24 May '11

24 May '11

At Thu, 28 Apr 2011 18:05:43 GMT, mslby(a)deshaw.com wrote: > My company uses OpenLDAP 2.4.25 with Berkeley DB 4.8.30 compiled on Solaris > 10 x86 using Sun Studio. OpenLDAP is used as the backend for generic naming > services (passwd, group, netgroup etc?) as well as holding mail routing and > some custom data. We have master and slave servers and are using syncrepl > refresh and persist. Are you using Solaris nss_ldap and ldap_cachemgr(1M) on your Solaris 10 with OpenLDAP slapd? If so, Solaris libldap.so breaks your slapd process as the following scenario: (1) slapd calls some name service functions, e.g. getpwnam(3C). (2) Solaris nss_ldap (/usr/lib/nss_ldap.so.1) is loaded. (3) Solaris libldap.so (/usr/lib/libldap.so.5) is loaded. (4) Solaris libldap.so overrides ldap_*() and ber_*() functions in slapd (or OpenLDAP libldap_r.so and liblber.so). (5) OpenLDAP calls ldap_*() and ber_*() functions that are belong to Solaris libldap.so, not OpenLDAP's one. See also: http://www.openldap.org/lists/openldap-technical/200902/msg00000.html https://bugzilla.mozilla.org/show_bug.cgi?id=292127 http://bugzilla.padl.com/show_bug.cgi?id=203 -- -- Name: SATOH Fumiyasu (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- Personal Home: http://www.SFO.jp/blog/ > Lately we have been experiencing hangs with slapd and I cannot figure out > what the cause is. Things will be humming along and then slapd will simply > stop accepting connections and answering any requests for reads/writes. We > have set the loglevel to 256 and there is nothing in the logs that > indicates what the issue it. At the time that the process goes catatonic all > syslogs from slapd stop > > I have not found a way to reproduce this on demand. > > Today we have had three hangs and the truss ouput is exactly the same on > all process. Once the slapd process gets in this state a simple kill does > not work. The syslog always says that slapd is waiting for tasks to > complete but this never happens. I need to kill -9 the pid. > > I am going to include all of the debug info that I have collected and > hopefully someone will have some idea what is going on. I also have a gcore > of the process if anyone wants and info from that > > All and any help is greatly appreciated

1 0

Re: (ITS#6950) pcache crashing when '+' or '*' is used in attrsets
by Ralf Haferkamp 24 May '11

24 May '11

'1.1' is also causing a crash (on shutdown)

1 0

(ITS#6950) pcache crashing when '+' or '*' is used in attrsets
by ralf＠OpenLDAP.org 24 May '11

24 May '11

Full_Name: Ralf Haferkamp Version: 2.4.25/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.222.177) Submitted by: ralf The pcache overlay crashes slapd when using * or + in a pcacheAttrset. It seems the problem was introduced with the recent changes to support caching of undefined attributes. Fix is on the way.

1 0

Re: (ITS#6941
by rhafer＠suse.de 24 May '11

24 May '11

> Some how this got duplicated from ITS#6940, please close. Done.

1 0

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

24 May '11

On 05/23/2011 10:15 PM, Tim.Mooney(a)ndsu.edu wrote: > Thank you Pierangelo. We've been running with that patch since last > Friday without problems, so I'm comfortable with the fix. > > If you can do so without having to spend much time on it, could you give > a brief overview of what you believe might be involved in implementing the > longer fix? I won't make any promises, but if you give me a hint at what > would be involved, I might be able to contribute the code to skip mapping > when not needed. That seems like it would be very beneficial. I don't think it's worth the effort, because mapping and rewriting are somehow tightly joined, so as soon as the overlay is loaded it is nearly always worth to scan all data to check whether intervention is needed. Further optimization would make the code even more hairy without significant improvements. p.

1 0

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

23 May '11

In regard to: Re: (ITS#6943) segfault in rwmmap in 2.4.25, Pierangelo...: > On 05/20/2011 10:21 PM, Tim.Mooney(a)ndsu.edu wrote: >> 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? > > Yes. Fixed in HEAD. Thanks, p. Thank you Pierangelo. We've been running with that patch since last Friday without problems, so I'm comfortable with the fix. If you can do so without having to spend much time on it, could you give a brief overview of what you believe might be involved in implementing the longer fix? I won't make any promises, but if you give me a hint at what would be involved, I might be able to contribute the code to skip mapping when not needed. That seems like it would be very beneficial. Tim -- Tim Mooney Tim.Mooney(a)ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164

1 0

(ITS#6949) OpenLDAP Logging
by andrew.stringer＠igt.com 23 May '11

23 May '11

Full_Name: Andrew Stringer Version: @(#) $OpenLDAP: slapd 2.3.43 OS: Red Hat 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.205.160.142) Software Enhancement Requests Hi, we are currently rebuilding our LDAP tree using vendor current version of software, including openLDAP. I don't have much LDAP experience, so may be there is already a way to do this, but I have not found it despite several trips to Google. etc.. Logging in openldap seems to be all via syslog and controlled by a value made up by adding the code for a particular log entry of interest, all of which are sent to syslog under one facility number. I feel that logging could be improved by allowing logging similar to how BIND's named does it, namely having different log files for queries, normal operational logs and zone transfers (or in LDAP's case, replications). This would make it much easier to monitor the activity of the server without having to grep out unwanted information to see the required detail. Regards, Andrew.

1 0

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

23 May '11

On 05/20/2011 10:21 PM, Tim.Mooney(a)ndsu.edu wrote: > 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? Yes. Fixed in HEAD. Thanks, p.

1 0

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

22 May '11

Hello Quanah, Our slapd uses back-meta to communicate to other slapds. We have to fulfill some requirements related with bandwith with network latencies and packet loss between slapds, to fulfill such requirements we need to increase these threads. Best Regards -----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: viernes, 20 de mayo de 2011 19:01 To: Jorge Perez Burgos; openldap-its(a)openldap.org Subject: Re: (ITS#6944) Add option to limit or remove operation list cache --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#6948) slaptest fails a converting a working cn=config from a .conf with a pcache configuration
by tgates81＠gmail.com 22 May '11

22 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 17 May '11

17 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 11 May '11

11 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 11 May '11

11 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

(ITS#6932) Strange assert()s
by h.b.furuseth＠usit.uio.no 05 May '11

05 May '11

Full_Name: Hallvard B Furuseth Version: master, 2.4.24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Klocwork reports a number of strange assert()s, typically assert(function parameter != NULL) after dereferencing it. Also some pointless ones, like if (ptr->foo) { bar = ptr; assert(bar != NULL); } I'll move these, along with some not found by Klocwork. At the same time, I'll change some nearby code to use alredy-computed values, e.g. be = op->o_bd; bi = op->o_bd->bd_info; can become bi = be->bd_info;

1 0

(ITS#6931) ldap_get_option(NULL, LDAP_OPT_SESSION_REFCNT, ) crash
by h.b.furuseth＠usit.uio.no 05 May '11

05 May '11

Full_Name: Hallvard B Furuseth Version: master, 2.4.24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) Submitted by: hallvard ldap_get_option(,LDAP_OPT_SESSION_REFCNT,) does not catch ld=NULL. Klocwork issue#111. Fixing.

1 0

Re: (ITS#6918) #include statement unsafe
by h.b.furuseth＠usit.uio.no 05 May '11

05 May '11

hyc(a)symas.com writes: >quanah(a)zimbra.com wrote: >> --On Monday, May 02, 2011 12:53 PM +0000 h.b.furuseth(a)usit.uio.no wrote: >> >>> hyc(a)symas.com writes: >>>> Nothing in the OpenLDAP code issues a truncate operation of any sort. >>> >>> There are several fopen(filename, "w") calls, which truncate the file. >>> Maybe the error confuses slapd so it takes a detour into one of them. > > Irrelevant. In Windows the OS prevents you from writing to an executable file > that is currently running. I.e., it is impossible for this to be the cause. Aha. OK. I don't know Windows, so I was reacting to what you said, not to what you didn't say:-) > Try it yourself: Can't without Windows. > (...) > If you still believe it's happening inside slapd the obvious thing to do to > track this is to run slapd under gdb and set a few breakpoints. E.g., one at > the end of the config parser, and one at slapd's call to exit(). At each > breakpoint, check the filesize of the slapd.exe. Something like that was what I had in mind, yes. I might try anyway. -- Hallvard

1 0

(ITS#6930) Socket leak in ldap_connect_to_path(too long path)
by h.b.furuseth＠usit.uio.no 05 May '11

05 May '11

Full_Name: Hallvard B Furuseth Version: master, 2.4.24 OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) Submitted by: hallvard ldap_connect_to_path() verifies its parameters after instead of before socket(), and does not close the socket on failure. Also the cleanup code can be simplified. Found by Klocwork, issue#117.

1 0

(ITS#6929) lutil_get_filed_password() filed descriptor leak
by h.b.furuseth＠usit.uio.no 05 May '11

05 May '11

Full_Name: Hallvard B Furuseth Version: HEAD, 2.4.24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard lutil_get_filed_password() does not always close the file on error. Found with Klocwork: Issue #203. Fixing.

1 0

Re: (ITS#6918) #include statement unsafe
by hyc＠symas.com 05 May '11

05 May '11

quanah(a)zimbra.com wrote: > --On Monday, May 02, 2011 12:53 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > >> hyc(a)symas.com writes: >>> Nothing in the OpenLDAP code issues a truncate operation of any sort. >> >> There are several fopen(filename, "w") calls, which truncate the file. >> Maybe the error confuses slapd so it takes a detour into one of them. Irrelevant. In Windows the OS prevents you from writing to an executable file that is currently running. I.e., it is impossible for this to be the cause. Try it yourself: #include <stdio.h> main(int argc, char *argv[]) { FILE *f=fopen(argv[0], "w"); if (f) printf("opened!\n"); else printf("failed!\n"); } >> Quanah, can you provide a full slapd.conf and command line which causes >> this? Not that I have a Windows box to test it on, but still... > > The command line was just slapd.exe -d -1 -f slapd.conf > > The slapd.conf itself is fairly small. The line that wrapped was the > include for inetOrgPerson. Everything obviously stopped when it hit the > wrapped include. > > ucdata-path "/opt/zimbra/openldap/ucdata" > include "/opt/zimbra/openldap/etc/openldap/schema/core.schema" > include "/opt/zimbra/openldap/etc/openldap/schema/cosine.schema" > include > "/opt/zimbra/openldap/etc/openldap/schema/inetorgperson.schema" Yes, but since "everything obviously stopped" there's nothing in slapd that fopen's any files from that point. First of all this problem cannot be specific to the include statement, since the input validation will reject the line before ever going anywhere the code for include handling. So, you ought to be able to reproduce this issue using any config statement that requires a single argument. Second, slapd stops all parsing and simply exits when it hits a config error. And this is early enough in the config file that nothing else has been initialized yet, so the teardown processing has very little to do. If you still believe it's happening inside slapd the obvious thing to do to track this is to run slapd under gdb and set a few breakpoints. E.g., one at the end of the config parser, and one at slapd's call to exit(). At each breakpoint, check the filesize of the slapd.exe. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6928) slapd: daemon.c:942: slapd_clr_write: Assertion `((slap_daemon[id].sd_index[(s)]) != -1)' failed.
by michael＠stroeder.com 05 May '11

05 May '11

The root cause in this case is that the schema differs on the consumer and schema violation errors were logged at the consumer. Obviously this is a configuration error but the provider should not crash because of this!

1 0

(ITS#6928) slapd: daemon.c:942: slapd_clr_write: Assertion `((slap_daemon[id].sd_index[(s)]) != -1)' failed.
by michael＠stroeder.com 05 May '11

05 May '11

Full_Name: Michael Ströder Version: 2.4.25 OS: URL: Submission from: (NULL) (195.145.144.134) slapd (serving as provider) crashes from time to time (several times today!) when a consumer has some problems. I suspect this is related to ITS#6922 and therefore I suspect that Howard's answer is again just "there is no issue". The last lines in the logs always show that the consumer already sent an UNBIND and after that slapd dies with this failed assertion. conn=1090 op=1 INTERM oid=1.3.6.1.4.1.4203.1.9.1.4 conn=1090 op=2 UNBIND conn=1090 fd=112 closed connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! slapd: daemon.c:942: slapd_clr_write: Assertion `((slap_daemon[id].sd_index[(s)]) != -1)' failed. /infraldap/sbin/start-slapd.sh: line 16: 28888 Aborted ${OPENLDAP_PREFIX}/libexec/slapd -h "ldap://0.0.0.0:389 ldaps://0.0.0.0:636 ldapi://%2ftmp%2finfraldap-socket????x-mod=0770" -d config,stats,stats2,sync -n slapd-e2-infra-ldap -u openldap -g openldap -f ${SLAPD_CONF}

1 0

Re: (ITS#6926) Delta-Sync produce undefined situation after split-brain
by Howard Chu 04 May '11

04 May '11

Delta-Syncrepl is only single-master. Closing this ITS.

1 0

Re: (ITS#6927) smbk5pwd handles DST incorrectly
by hyc＠symas.com 04 May '11

04 May '11

ryans(a)aweber.com wrote: > Full_Name: Ryan Steele > Version: 2.4.23 > OS: Ubuntu Server 10.04 (Lucid) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (207.106.239.81) > > > The smbk5pwd overlay (I tested with an older version and HEAD) seems to handle > Daylight Savings Time incorrectly when it comes to the sambaPwdLastSet > attribute, populating it with a value that does not take DST into account. As > an example, consider the following attributes from one of the entries in my > directory: > > pwdChangedTime: 20110502160329Z > sambaPwdLastSet: 1304352209 > > Obviously, pwdChangedTime specifies the timestamp: > > Mon May 2 16:03:29 EDT 2011 > > On the other hand, sambaPwdLastSet specifies the timestamp as being an hour > later, as calculated with the 'date' command (date -d'1970-01-01 1304352209 > sec'): > > Mon May 2 17:03:29 EDT 2011 > > Right now we're in DST on the east coast, which is GMT -0400. This would mean > that pwdChangedTime is correct, but sambaPwdLastSet is still incorrectly > calculating results using GMT -0500. The sambaPwdLastSet value is not calculated at all, it is exactly what the OS system clock returns, and the OS system clock is in UTC so DST is irrelevant. Probably your machine's timezone is misconfigured; notice that pwdChangedTime is also in UTC so 20110502160329Z cannot be "May 2 16:03:29 EDT". Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6927) smbk5pwd handles DST incorrectly
by ryans＠aweber.com 04 May '11

04 May '11

Full_Name: Ryan Steele Version: 2.4.23 OS: Ubuntu Server 10.04 (Lucid) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (207.106.239.81) The smbk5pwd overlay (I tested with an older version and HEAD) seems to handle Daylight Savings Time incorrectly when it comes to the sambaPwdLastSet attribute, populating it with a value that does not take DST into account. As an example, consider the following attributes from one of the entries in my directory: pwdChangedTime: 20110502160329Z sambaPwdLastSet: 1304352209 Obviously, pwdChangedTime specifies the timestamp: Mon May 2 16:03:29 EDT 2011 On the other hand, sambaPwdLastSet specifies the timestamp as being an hour later, as calculated with the 'date' command (date -d'1970-01-01 1304352209 sec'): Mon May 2 17:03:29 EDT 2011 Right now we're in DST on the east coast, which is GMT -0400. This would mean that pwdChangedTime is correct, but sambaPwdLastSet is still incorrectly calculating results using GMT -0500.

1 0

(ITS#6926) Delta-Sync produce undefined situation after split-brain
by sascha.kuehndel＠deka.de 04 May '11

04 May '11

Full_Name: Sascha Kuehndel Version: 2.4.25 OS: HP-UX 11.31 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.166.104.102) Hi, i tested the delta-sync in a multi-master (2 master) architecture. In a split-brain szenario the sync produced an undefinded state. Some times the data wasn't synchronized (both master hold there data unchanged), sometimes the data was fliped (master1 take data from master2, and master2 from master1). A defined and synchronized state must reached after the end of the split-brain. Senario: 1. master1 and master2 runs in sync 2. shutdown of master2 3. data change on master1 4. shutdown of master1 5. start of master2 6. data change on master2 (the same attribute on the same object, other value) > now the masters are out of sync in the same field 7. restart of master1 8. the sync process is running 9. take a look on the change field.. there are different regards Sascha Kuehndel PS - Nice to have: The posibility to define the action in thouch an situation - master1 or master2... wins - the newest win - or no change and the posibility to write a log-entry about it (with the exact dn,the attribute and the values before the synchronization)

1 0

Re: (ITS#6918) #include statement unsafe
by quanah＠zimbra.com 03 May '11

03 May '11

--On Monday, May 02, 2011 12:53 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > hyc(a)symas.com writes: >> Nothing in the OpenLDAP code issues a truncate operation of any sort. > > There are several fopen(filename, "w") calls, which truncate the file. > Maybe the error confuses slapd so it takes a detour into one of them. > > Quanah, can you provide a full slapd.conf and command line which causes > this? Not that I have a Windows box to test it on, but still... The command line was just slapd.exe -d -1 -f slapd.conf The slapd.conf itself is fairly small. The line that wrapped was the include for inetOrgPerson. Everything obviously stopped when it hit the wrapped include. ucdata-path "/opt/zimbra/openldap/ucdata" include "/opt/zimbra/openldap/etc/openldap/schema/core.schema" include "/opt/zimbra/openldap/etc/openldap/schema/cosine.schema" include "/opt/zimbra/openldap/etc/openldap/schema/inetorgperson.schema" include "/opt/zimbra/openldap/etc/schema/amavisd.schema" include "/opt/zimbra/openldap/etc/schema/zimbra.schema" pidfile "/opt/zimbra/openldap/var/run/slapd.pid" argsfile "/opt/zimbra/openldap/var/run/slapd.args" modulepath /opt/zimbra/openldap/openldap moduleload back_bdb-2-4-2.dll moduleload back_monitor-2-4-2.dll access to dn.subtree="" by dn.children="cn=admins,cn=zimbra" write by * break access to dn.base="" by * read access to dn.base="cn=Subschema" by * read database config rootpw {SSHA}8+r0nkcErptqasSrFPcT0k81NFrbTcAS database monitor rootdn "cn=config" access to dn.children="cn=monitor" by dn.children="cn=admins,cn=zimbra" read database bdb suffix "" rootdn "cn=config" cachesize 10000 idlcachesize 10000 checkpoint 64 5 directory "/opt/zimbra/data/ldap/hdb/db" index objectClass eq index uid pres,eq index entryUUID eq index entryCSN eq sizelimit unlimited timelimit unlimited access to attrs=userPassword by anonymous auth by dn.children="cn=admins,cn=zimbra" write access to dn.subtree="cn=zimbra" by dn.children="cn=admins,cn=zimbra" write access to attrs=zimbraZimletUserProperties,zimbraGalLdapBindPassword,zimbraGalLdapBindDn,zimbraAuthTokenKey,zimbraPreAuthKey,zimbraPasswordHistory,zimbraIsAdminAccount,zimbraAuthLdapSearchBindPassword by dn.children="cn=admins,cn=zimbra" write by * none access to filter=(!(zimbraHideInGal=TRUE)) attrs=cn,co,company,dc,displayName,givenName,gn,initials,l,mail,o,ou,physicalDeliveryOfficeName,postalCode,sn,st,street,streetAddress,telephoneNumber,title,uid by dn.children="cn=admins,cn=zimbra" write by dn.exact="uid=zmpostfix,cn=appaccts,cn=zimbra" read by * read access to attrs=objectclass,zimbraId,zimbraMailAddress,zimbraMailAlias,zimbraMailCanonicalAddress,zimbraMailCatchAllAddress,zimbraMailCatchAllCanonicalAddress,zimbraMailCatchAllForwardingAddress,zimbraMailDeliveryAddress,zimbraMailForwardingAddress,zimbraPrefMailForwardingAddress,zimbraMailHost,zimbraMailStatus,zimbraMailTransport,zimbraDomainName,zimbraDomainType,zimbraPrefMailLocalDeliveryDisabled by dn.children="cn=admins,cn=zimbra" write by dn.exact="uid=zmpostfix,cn=appaccts,cn=zimbra" read by * read access to attrs=entry by dn.children="cn=admins,cn=zimbra" write by * read --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6912) authz-regexp DN normalization of authcIDs
by daniel＠pluta.biz 03 May '11

03 May '11

In case authcIDs do not need to be normalized, this seems to be a better place to disable normalization: ftp://ftp.openldap.org/incoming/Daniel-Pluta-110502.patch Now authzIDs of the form "u:xxxx" are also affected.

1 0

(ITS#6925) [PATCH] Use inet_ntop for server when available
by delphij＠gmail.com 02 May '11

02 May '11

Full_Name: Xin LI Version: 2.4.25 OS: FreeBSD/amd64 9.0-CURRENT URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (206.40.55.65) slapd uses inet_ntoa in several places and some of them does not use inet_ntop when it's available. The inet_ntoa is not thread-safe on FreeBSD and thus could cause denial of service if it loses the race, when an IP based ACL is in effect. diff --git a/servers/slapd/connection.c b/servers/slapd/connection.c index aea3b39..65ce576 100644 --- a/servers/slapd/connection.c +++ b/servers/slapd/connection.c @@ -1500,12 +1500,21 @@ connection_input( Connection *conn , conn_readinfo *cri ) #ifdef LDAP_CONNECTIONLESS if ( conn->c_is_udp ) { char peername[sizeof("IP=255.255.255.255:65336")]; + const char *peeraddr = NULL; len = ber_int_sb_read(conn->c_sb, &peeraddr, sizeof(struct sockaddr)); if (len != sizeof(struct sockaddr)) return 1; +#if defined( HAVE_GETADDRINFO ) && defined( HAVE_INET_NTOP ) + char addr[INET_ADDRSTRLEN]; + inet_ntop( AF_INET, &peeraddr.sa_in_addr.sin_addr, + addr, sizeof(addr) ); + peeraddr = addr; +#else /* ! HAVE_GETADDRINFO || ! HAVE_INET_NTOP */ + peeraddr = inet_ntoa( peeraddr.sa_in_addr.sin_addr ); +#endif /* ! HAVE_GETADDRINFO || ! HAVE_INET_NTOP */ sprintf( peername, "IP=%s:%d", - inet_ntoa( peeraddr.sa_in_addr.sin_addr ), + peeraddr, (unsigned) ntohs( peeraddr.sa_in_addr.sin_port ) ); Statslog( LDAP_DEBUG_STATS, "conn=%lu UDP request from %s (%s) accepted.\n", diff --git a/servers/slapd/daemon.c b/servers/slapd/daemon.c index 8e8a69d..ccfa2ee 100644 --- a/servers/slapd/daemon.c +++ b/servers/slapd/daemon.c @@ -1971,8 +1971,16 @@ slap_listener( # ifdef LDAP_PF_INET6 case AF_INET6: if ( IN6_IS_ADDR_V4MAPPED(&from.sa_in6_addr.sin6_addr) ) { +#if defined( HAVE_GETADDRINFO ) && defined( HAVE_INET_NTOP ) + char addr[INET_ADDRSTRLEN]; + inet_ntop( AF_INET, + ((struct in_addr *)&from.sa_in6_addr.sin6_addr.s6_addr[12]), + addr, sizeof(addr) ); + peeraddr = addr; +#else /* ! HAVE_GETADDRINFO || ! HAVE_INET_NTOP */ peeraddr = inet_ntoa( *((struct in_addr *) &from.sa_in6_addr.sin6_addr.s6_addr[12]) ); +#endif /* ! HAVE_GETADDRINFO || ! HAVE_INET_NTOP */ sprintf( peername, "IP=%s:%d", peeraddr != NULL ? peeraddr : SLAP_STRING_UNKNOWN, (unsigned) ntohs( from.sa_in6_addr.sin6_port ) ); @@ -1989,12 +1997,19 @@ slap_listener( break; # endif /* LDAP_PF_INET6 */ - case AF_INET: + case AF_INET: { +#if defined( HAVE_GETADDRINFO ) && defined( HAVE_INET_NTOP ) + char addr[INET_ADDRSTRLEN]; + inet_ntop( AF_INET, &from.sa_in_addr.sin_addr, + addr, sizeof(addr) ); + peeraddr = addr; +#else /* ! HAVE_GETADDRINFO || ! HAVE_INET_NTOP */ peeraddr = inet_ntoa( from.sa_in_addr.sin_addr ); +#endif /* ! HAVE_GETADDRINFO || ! HAVE_INET_NTOP */ sprintf( peername, "IP=%s:%d", peeraddr != NULL ? peeraddr : SLAP_STRING_UNKNOWN, (unsigned) ntohs( from.sa_in_addr.sin_port ) ); - break; + } break; default: slapd_close(sfd);

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs