- openldap-bugs - openldap.org

Re: (ITS#4971) patch for OpenLDAP 2-3-32
by ando＠sys-net.it 18 May '07

18 May '07

jemeterisan(a)mail.ru wrote: > I had noticed, that the patch, used for 'schema-map.c' doesn't work > correct. I hope, You also had checked it up. So what had I found in > the function 'backsql_ad2at': > The attribute name is stored in 'struct berval' structure, so if > You change '.bv_val' from 'userCertificate;binary' to > 'userCertificate', You should change '.bv_len' in accordance to > strlen(aaa.bv_val) without strlen(";binary"). I assume you refer to a patch that was submitted along with ITS#4868; that patch is absolutely incorrect and in fact it has been rejected. A consistent fix has been applied to hEAD code. It has never been backported to OpenLDAP 2.3 because nobody fed back about it. If you wish to test HEAD code and report success, I'll be happy to backport it to OpenLDAP 2.3 so that it gets released with the next release. > And by the way I want to store 'userCertificate' attribute type in PostrgreSQL. > > What type of the field in the table should I use? Any blob-like format would be fine (although I haven't tested it with PostgreSQL yet). > Just another question to the developers: > I've heared that OpenLDAP is sensible to DOS attacks, so, how can I avoid this > trouble? And I want to know more about this problem, if possible. Please direct software use related questions to the openldap-software mailing list. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#4972) thr_debug problems
by h.b.furuseth＠usit.uio.no 18 May '07

18 May '07

Full_Name: Hallvard B Furuseth Version: HEAD, RE23 OS: URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard $LDAP_THREAD_DEBUG parsing is bogus, code in the inner loop should be outside it. Detached threads can validly exit after ldap_debug_thread_destroy() (fixed in HEAD). Valgrind carries the 'uninialized' state out of debug_already_initialized(). RE23/thr_debug.c has some other problems that are fixed in HEAD, but take a bit more work to fix and test. I'll align it with HEAD if anyone is interested.

1 0

Re: (ITS#4961) If database suffix is ""
by ali.pouya＠free.fr 18 May '07

18 May '07

Unfortunately the problem has not been completely fixed in the HEAD. With the fix in the head the error message disappears but the contextCSN ins NOT ACTUALLY written to the disk. So at the next slapd startup the ContextCSN is missing. An the servers hav to resynchronize. Below you find the log extract. Thanks Best regards Ali ============================ Log extract : daemon: shutdown requested and initiated. daemon: closing 7 connection_closing: readying conn=0 sd=11 for close connection_close: conn=0 sd=11 daemon: removing 11 conn=0 fd=11 closed (slapd shutdown) =>do_syncrepl rid=123 connection_get(12) connection_get(12): got connid=0 daemon: removing 12r slapd shutdown: waiting for 1 threads to terminate ldap_free_request (origid 2, msgid 2) ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 12 0000: 30 05 02 01 03 42 00 0....B. ldap_write: want=7, written=7 0000: 30 05 02 01 03 42 00 0....B. ldap_free_connection: actually freed slapd shutdown: initiated bdb_modify: bdb_dn2entry("") bdb_modify_internal: 0x00000000: <= acl_access_allowed: granted to database root bdb_modify_internal: replace contextCSN is_entry_objectclass("", "2.5.17.0") no objectClass attribute => entry_encode(0x00000000): bdb_modify: updated id=00000000 dn="" send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=0 matched="" text="" ====> bdb_cache_release_all slapd destroy: freeing system resources. slapd stopped.

1 0

Re: (ITS#4965) slapd stops if access to cn=monitor is restricted
by ali.pouya＠free.fr 18 May '07

18 May '07

Hi Pierangelo; The HEAD misses some new definitions (see followup 5 in ITS 4959) so I reproduced the problem with OPENLDAP_REL_ENG_2_4. I feel that the problem has not been fixed in this release. Thanks and best regards Ali

1 0

Re: (ITS#4959) replica seg faults if syncrepl searchbase =""
by ali.pouya＠free.fr 18 May '07

18 May '07

Hi Pierangelo; The HEAD misses some new definitions (see below) so I reproduced the problem with OPENLDAP_REL_ENG_2_4. The backtrace is the same as before : #0 0x00179d5a in strcmp () from /lib/tls/libc.so.6 #1 0x08068ede in select_backend (dn=0xb78bef5c, manageDSAit=0, noSubs=0) at backend.c:684 #2 0x0806a8ac in fe_aux_operational (op=0xb78bef40, rs=0xb78bee80) at backend.c:1779 #3 0x0806a01b in backend_operational (op=0xb78bef40, rs=0xb78bee80) at backend.c:1801 #4 0x080a7d06 in do_syncrepl (ctx=0xb78bf2a0, arg=0x88ab2e0) at syncrepl.c:547 #5 0x081281c3 in ldap_int_thread_pool_wrapper (xpool=0x886fd78) at tpool.c:704 #6 0x00907371 in start_thread () from /lib/tls/libpthread.so.0 #7 0x001d8ffe in clone () from /lib/tls/libc.so.6 =============== N.B. The HEAD misses the definition of 'oids' 'oid_name', etc. So I get the following error at build time : tls.c:2908: error: syntax error before '*' token tls.c: In function `find_oid': tls.c:2913: error: `oids' undeclared (first use in this function) tls.c:2913: error: (Each undeclared identifier is reported only once tls.c:2913: error: for each function it appears in.) tls.c: In function `ldap_X509dn2bv': tls.c:2946: error: `oid_name' undeclared (first use in this function) tls.c:2946: error: `oidname' undeclared (first use in this function) make[2]: *** [tls.lo] Erreur 1 make[2]: Leaving directory `/var/ali/openldap-2.4/head-170507/libraries/libldap' make[1]: *** [all-common] Erreur 1 make[1]: Leaving directory `/var/ali/openldap-2.4/head-170507/libraries' make: *** [all-common] Erreur 1 Thanks Best Regards Ali

1 0

(ITS#4971) patch for OpenLDAP 2-3-32
by jemeterisan＠mail.ru 18 May '07

18 May '07

Full_Name: Petrov Dmitry Version: 2-3-32 OS: Red Hat 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.195.208.66) Hi, guys! I had noticed, that the patch, used for 'schema-map.c' doesn't work correct. I hope, You also had checked it up. So what had I found in the function 'backsql_ad2at': The attribute name is stored in 'struct berval' structure, so if You change '.bv_val' from 'userCertificate;binary' to 'userCertificate', You should change '.bv_len' in accordance to strlen(aaa.bv_val) without strlen(";binary"). And by the way I want to store 'userCertificate' attribute type in PostrgreSQL. What type of the field in the table should I use? Just another question to the developers: I've heared that OpenLDAP is sensible to DOS attacks, so, how can I avoid this trouble? And I want to know more about this problem, if possible. With best wishes, Dmitry...

1 0

(ITS#4970) Problem between pwdReset and pwdMinAge
by py.bonnetain＠ba-consultants.fr 17 May '07

17 May '07

Full_Name: Pierre-Yves Bonnetain Version: 2.3.35 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.162.162) There is something "forgotten" in ppolicy overlay code. When pwdReset is set to TRUE, the user is properly asked to change his password. BUT if the (admin-made) previous password change is newer than pwdMinAge, the requested password change will be rejected with a "password too young" message : ----------- $ ssh somehost -l someuser Password: You are required to change your LDAP password immediately. Enter login(LDAP) password: New UNIX password: Retype new UNIX password: LDAP password information update failed: Constraint violation Password is too young to change ----------- The pwdMinAge parameter should be ignored when pwdReset is set, otherwise the user will effectively be locked out of his account while waiting for the minimum delay to expire. Here is a patch to correct this behavior. Proposed patch may not adhere to coding standards and such, so feel free to enhance it as needed . *** ppolicy.old 2007-02-08 13:31:24.000000000 +0100 --- ppolicy.c 2007-05-17 17:10:39.000000000 +0200 *************** *** 1696,1710 **** time_t pwtime = (time_t)-1, now; int age; ! if ((pa = attr_find( e->e_attrs, ad_pwdChangedTime )) != NULL) ! pwtime = parse_time( pa->a_nvals[0].bv_val ); ! now = slap_get_time(); ! age = (int)(now - pwtime); ! if ((pwtime != (time_t)-1) && (age < pp.pwdMinAge)) { ! rs->sr_err = LDAP_CONSTRAINT_VIOLATION; ! rs->sr_text = "Password is too young to change"; ! pErr = PP_passwordTooYoung; ! goto return_results; } } --- 1696,1716 ---- time_t pwtime = (time_t)-1, now; int age; ! /* Py Bonnetain, B&A Consultants : We DON'T CARE for minAge if pwdReset ! is set. */ ! if ((pa = attr_find( e->e_attrs, ad_pwdReset )) == NULL || ! ! bvmatch( &pa->a_nvals[0], &slap_true_bv) ) { ! ! if ((pa = attr_find( e->e_attrs, ad_pwdChangedTime )) != NULL) ! pwtime = parse_time( pa->a_nvals[0].bv_val ); ! now = slap_get_time(); ! age = (int)(now - pwtime); ! if ((pwtime != (time_t)-1) && (age < pp.pwdMinAge)) { ! rs->sr_err = LDAP_CONSTRAINT_VIOLATION; ! rs->sr_text = "Password is too young to change"; ! pErr = PP_passwordTooYoung; ! goto return_results; ! } } }

1 0

Re: (ITS#4965) slapd stops if access to cn=monitor is restricted
by ando＠sys-net.it 17 May '07

17 May '07

ali.pouya(a)free.fr wrote: > If I include the monitor back-end in my configuration I have to add the > following access rule as well : > > access to dn.sub="cn=monitor" by * read > > Otherwise slapd stops with the log reproduced below (my access rules include > "access to * by * none"). The problem is already fixed in HEAD: slapd starts, although it cannot register back-bdb monitor stuff unless a roodn is defined in the monitor backend. FFT: maybe the monitor database could have a default rootdn "cn=Monitor", much like the config database? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4968) acl problem
by ando＠sys-net.it 17 May '07

17 May '07

zeaal_3(a)yahoo.com wrote: > Full_Name: dhiren > Version: 2.2 > OS: fedora4 > URL: > Submission from: (NULL) (203.88.149.100) > > > when i enable following acl , user not able to login client side:- > > access to attrs=userPassword > by self write > by anonymous auth > by * none > > whts problem? when disable this acl user can login. Please direct software usage questions to the openldap-software list; or, just read the first few lines of slapd.conf(5) and find the answer yourself. This ITS will be closed. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#4969) globalization missing is com.novell.ldap.resources package
by viral_barot＠persistent.co.in 17 May '07

17 May '07

Full_Name: viral barot Version: 2.3 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (220.225.70.2) It is found that package com.novell.ldap.resources does not include many language files for globalization support. This package contains only english and spanish (ResultCodeMessages.java and ResultCodeMessages_es.java) and other language files are missing. It would be fine if following files are included. ResultCodeMessages_ja.java ResultCodeMessages_ko.java ResultCodeMessages_it.java ResultCodeMessages_fr.java ResultCodeMessages_de.java ResultCodeMessages_pt_BR.java ResultCodeMessages_zh_CN.java ResultCodeMessages_zh_TW.java Thanks.

1 0

(ITS#4968) acl problem
by zeaal_3＠yahoo.com 17 May '07

17 May '07

Full_Name: dhiren Version: 2.2 OS: fedora4 URL: Submission from: (NULL) (203.88.149.100) when i enable following acl , user not able to login client side:- access to attrs=userPassword by self write by anonymous auth by * none whts problem? when disable this acl user can login.

1 0

(ITS#4966) OpenLDAP 2.3.35 crashes on valsort overlay
by digant＠stanford.edu 16 May '07

16 May '07

Full_Name: Digant C Kasundra Version: 2.3.35 OS: Debian 3.1 URL: ftp://ftp.openldap.org/incoming/digant-kasundra-20070516.txt Submission from: (NULL) (171.64.18.9) When modding an entry, valsort seems to have crashed the server. I've uploaded the stack trace and informaiton I was able to gather out of the core dump.

1 0

(ITS#4965) slapd stops if access to cn=monitor is restricted
by ali.pouya＠free.fr 16 May '07

16 May '07

Full_Name: Ali Pouya Version: 2.2.4alpha OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.242.3.30) If I include the monitor back-end in my configuration I have to add the following access rule as well : access to dn.sub="cn=monitor" by * read Otherwise slapd stops with the log reproduced below (my access rules include "access to * by * none"). I can send more information if required. Thanks and best regards Ali ============================================= Log extract : >>> dnPretty: <c=fr> => ldap_bv2dn(c=fr,0) <= ldap_bv2dn(c=fr)=0 => ldap_dn2bv(272) <= ldap_dn2bv(c=fr)=0 <<< dnPretty: <c=fr> >>> dnNormalize: <c=fr> => ldap_bv2dn(c=fr,0) <= ldap_bv2dn(c=fr)=0 => ldap_dn2bv(272) <= ldap_dn2bv(c=fr)=0 <<< dnNormalize: <c=fr> end get_filter 0 => monitor_back_search => access_allowed: search access to "cn=Databases,cn=Monitor" "entry" requested => acl_get: [2] attr entry => acl_mask: access to entry "cn=Databases,cn=Monitor", attr "entry" requested => acl_mask: to all values by "", (=0) <= check a_dn_pat: cn=admin,ou=internal,ou=min,o=gouv,c=fr <= check a_dn_pat: cn=connecteur,ou=internal,ou=min,o=gouv,c=fr <= check a_dn_pat: cn=sync,ou=internal,ou=min,o=gouv,c=fr <= check a_dn_pat: ou=applications,ou=external,ou=min,o=gouv,c=fr <= check a_dn_pat: * <= acl_mask: [5] applying none(=0) (stop) <= acl_mask: [5] mask: none(=0) => slap_access_allowed: search access denied by none(=0) => access_allowed: no more rules send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=32 matched="" text="" monitor_back_register_entry_attrs(""): base="cn=databases,cn=monitor" scope=one filter="(namingContexts:distinguishedNameMatch:=c=fr)": unable to find entry ====> bdb_cache_release_all backend_startup_one: bi_db_open failed! (-1) slapd shutdown: initiated ====> bdb_cache_release_all bdb_db_close: alock_close failed slapd destroy: freeing system resources. slapd stopped. connections_destroy: nothing to destroy.

1 0

Re: Re: (ITS#4960) the memory increase qu ickly and not can be released sometime.
by hoverwf＠126.com 16 May '07

16 May '07

--Boundary-=_xCXZRVEUxxIpjyEYhiCoTxWoOQsJ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit hi Hallvard B Furuseth <h.b.furuseth(a)usit.uio.no> thanks, this is the reason why the memory increase. Pierangelo Masarati ando(a)sys-net.it sorry, next time i will surely discussion it on the OpenLDAP-software mailing list. --Boundary-=_xCXZRVEUxxIpjyEYhiCoTxWoOQsJ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable <DIV>      </DIV> <DIV>hi Hallvard B Furuseth <h.b.furuseth(a)usit.uio.no><BR> <DIV>           &n= bsp;    thanks,  this is the reason why the memory in= crease.  </DIV></DIV> <DIV> </DIV> <DIV> </DIV> <DIV>Pierangelo Masarati <A href=3D"mailto:ando@sys-net.it">ando(a)sys-net.= it</A></DIV> <DIV>           &n= bsp;    sorry,  next time i will surely discussi= on it on the OpenLDAP-software mailing list.</DIV> <DIV> </DIV><br><br><hr> <a style=3D"font-size:14px;line-height:15px; color:#000; text-decoration:= none" href=3D"http://event.mail.163.com/chanel/xyq.htm?from=3D126" target= =3D"_blank"><span style=3D"text-decoration:underline; color:blue">=C3=E2=B7= =D1=CA=D4=CD=E62006=D6=D0=B9=FA=D7=EE=BC=D1=CD=F8=C2=E7=D3=CE=CF=B7--=C3=CE= =BB=C3=CE=F7=D3=CE </span> </a> --Boundary-=_xCXZRVEUxxIpjyEYhiCoTxWoOQsJ--

1 0

Re: (ITS#4964) consumer with slapo-chain segfaults when using ldappasswd
by ando＠sys-net.it 15 May '07

15 May '07

krause(a)biochem.mpg.de wrote: > changing the the ldap password using "ldappasswd" from the command line using > the following slapd.conf on a consumer (only relevant part) crashes the server > with a "segmentation fault": The crash is now fixed in HEAD (a NULL pointer was parsed out of the referral's DN, since formally no request DN is available in that exop). However, although the password modify now is correctly resent to the producer, the consumer does not get updated. Investigating... p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#4964) consumer with slapo-chain segfaults when using ldappasswd
by krause＠biochem.mpg.de 15 May '07

15 May '07

Full_Name: Markus Krause Version: openldap2-2.3.34-5.2 OS: SuSE Llinux Enterprise Server 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.56.13.40) changing the the ldap password using "ldappasswd" from the command line using the following slapd.conf on a consumer (only relevant part) crashes the server with a "segmentation fault": ... modulepath /usr/lib/openldap/modules moduleload smbk5pwd.so sizelimit unlimited acl ... TLSstuff ... #### chain overlay definition overlay chain chain-rebind-as-user FALSE chain-uri "ldaps://ldapprov" chain-rebind-as-user TRUE chain-idassert-bind bindmethod="simple" binddn="cn=manager,o=test" credentials="secret" mode="self" database bdb suffix "o=test" directory /var/lib/ldap/ rootdn "cn=manager,o=test" rootpw "secret" index objectClass,uidNumber,gidNumber eq index member,mail eq,pres index cn,displayname,uid,sn,givenname sub,eq,pres index sambaSID,sambaPrimaryGroupSID,sambaDomainName eq index entryCSN,entryUUID eq index dhcpHWAddress eq,pres index relativeDomainName eq,pres index ipHostNumber eq,pres index zoneName eq,pres index radiusGroupName eq,pres syncrepl rid=13 provider=ldaps://ldapprov type=refreshAndPersist retry=1,5,5,6,30,+ interval=00:00:00:30 searchbase="o=test" filter="(objectclass=*)" scope=sub attrs="*" schemachecking=off binddn="cn=manager,o=test" bindmethod=simple credentials="secret" sizelimit=unlimited updateref ldaps://ldapprov overlay syncprov --- end of slapd.conf running slapd in debug mode -d 65535 shows: --- slapd -d 65535 conn=0 op=1 PASSMOD id="uid=test,o=test" new >>> dnPrettyNormal: <uid=user,o=test> => ldap_bv2dn(uid=user,o=test,0) <= ldap_bv2dn(uid=user,o=test)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=user,o=test)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=user,o=test)=0 <<< dnPrettyNormal: <uid=user,o=test>, <uid=user,o=test> bdb_dn2entry("uid=user,o=test") => bdb_dn2id("uid=user,o=test") <= bdb_dn2id: got id=0x0000284c => bdb_dn2id("o=test") <= bdb_dn2id: got id=0x00002861 => bdb_dn2id("uid=user,o=test") <= bdb_dn2id: got id=0x0000337f entry_decode: "uid=user,o=test" <= entry_decode(uid=user,o=test) ldap_url_parse_ext(ldaps://ldapprov) send_ldap_extended: err=10 oid= len=0 ldap_url_parse_ext(ldaps://ldapprov) Segmentation fault ----- end of debug output the command used was: ldappasswd -x -h localhost -D "cn=manager,o=test" -W uid=test,o=test -S New password: Re-enter new password: Enter LDAP Password: ldappasswd: ldap_result: Can't contact LDAP server (-1) the last 70 lines of strace where: --- tail -70 slapd-strace.log: time(NULL) = 1179248871 time(NULL) = 1179248871 close(14) = 0 close(15) = 0 close(13) = 0 lseek(12, 0, SEEK_SET) = 0 fcntl64(12, F_SETLKW, {type=F_WRLCK, whence=SEEK_CUR, start=0, len=1024}) = 0 fstat64(12, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0 lseek(12, 2048, SEEK_SET) = 2048 read(12, "xV4\22\0\0\0\0\2\0\0\0\0\0\0\0 \300IF\0\0\0\0\310~\0\0"..., 1024) = 1024 lseek(12, 2048, SEEK_SET) = 2048 fcntl64(12, F_GETLK, {type=F_UNLCK, whence=SEEK_CUR, start=0, len=1024, pid=0}) = 0 lseek(12, 2048, SEEK_SET) = 2048 read(12, "xV4\22\0\0\0\0\2\0\0\0\0\0\0\0 \300IF\0\0\0\0\310~\0\0"..., 1024) = 1024 lseek(12, 2048, SEEK_SET) = 2048 write(12, "xV4\22\0\0\0\0\0\0\0\0\0\0\0\0 \300IF\0\0\0\0\310~\0\0"..., 1024) = 1024 lseek(12, 3072, SEEK_SET) = 3072 read(12, "xV4\22\0\0\0\0\0\0\0\0\0\0\0\0 yHF\0\0\0\0\242q\0\0\0\0"..., 1024) = 1024 lseek(12, 0, SEEK_SET) = 0 fcntl64(12, F_SETLK, {type=F_UNLCK, whence=SEEK_CUR, start=0, len=1024}) = 0 stat64("/var/lib/ldap/id2entry.bdb", {st_mode=S_IFREG|0600, st_size=15826944, ...}) = 0 stat64("/var/lib/ldap/id2entry.bdb", {st_mode=S_IFREG|0600, st_size=15826944, ...}) = 0 open("/var/lib/ldap/id2entry.bdb", O_RDWR|O_LARGEFILE) = 13 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0 read(13, "\22\0\0\0\212^i\0\0\0\0\0b1\5\0\t\0\0\0\0@\0\0\0\t\0\0"..., 512) = 512 close(13) = 0 stat64("/var/lib/ldap/id2entry.bdb", {st_mode=S_IFREG|0600, st_size=15826944, ...}) = 0 open("/var/lib/ldap/id2entry.bdb", O_RDWR|O_LARGEFILE) = 13 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0 fstat64(13, {st_mode=S_IFREG|0600, st_size=15826944, ...}) = 0 time(NULL) = 1179248871 stat64("/var/lib/ldap/dn2id.bdb", {st_mode=S_IFREG|0600, st_size=5132288, ...}) = 0 stat64("/var/lib/ldap/dn2id.bdb", {st_mode=S_IFREG|0600, st_size=5132288, ...}) = 0 open("/var/lib/ldap/dn2id.bdb", O_RDWR|O_LARGEFILE) = 14 fcntl64(14, F_SETFD, FD_CLOEXEC) = 0 read(14, "\22\0\0\0\tEQ\0\0\0\0\0b1\5\0\t\0\0\0\0\20\0\0\0\t\0\0"..., 512) = 512 close(14) = 0 stat64("/var/lib/ldap/dn2id.bdb", {st_mode=S_IFREG|0600, st_size=5132288, ...}) = 0 open("/var/lib/ldap/dn2id.bdb", O_RDWR|O_LARGEFILE) = 14 fcntl64(14, F_SETFD, FD_CLOEXEC) = 0 fstat64(14, {st_mode=S_IFREG|0600, st_size=5132288, ...}) = 0 time(NULL) = 1179248871 pread64(13, "\20\0\0\0008\fY\0\1\0\0\0\0\0\0\0\0\0\0\0\2\0\344?\3\3"..., 16384, 16384) = 16384 pread64(13, "\22\0\0\0:^i\0\220\3\0\0\0\0\0\0\0\0\0\0\335\0010\"\2\3"..., 16384, 14942208) = 16384 pread64(13, "\22\0\0\0\235\0m\0W\3\0\0O\3\0\0\0\0\0\0\20\0\270!\1\5"..., 16384, 14008320) = 16384 mmap2(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb63c3000 time(NULL) = 1179248871 write(2, "=> bdb_entry_get: ndn: \"o=testh"..., 49) = 49 write(2, "=> bdb_entry_get: oc: \"(null)\", "..., 49) = 49 write(2, "bdb_dn2entry(\"o=test"..., 40) = 40 write(2, "=> bdb_dn2id(\"o=test"..., 40) = 40 pread64(14, "\t\0\0\0D+=\0\1\0\0\0\0\0\0\0\0\0\0\0\20\0\214\r\3\3\364"..., 4096, 4096) = 4096 pread64(14, "\n\0\0\0\212\242P\0_\2\0\0\0\0\0\0G\4\0\0G\0\364\7\2\3"..., 4096, 2486272) = 4096 pread64(14, "\22\0\0\0i\374l\0\n\0\0\0Q\3\0\0\33\4\0\0>\0\230\6\1\5"..., 4096, 40960) = 4096 write(2, "<= bdb_dn2id: got id=0x00000001\n", 32) = 32 pread64(13, "\20\0\0\0\230\313X\0\217\3\0\0\0\0\0\0\0\0\0\0\307\1\224"..., 16384, 14925824) = 16384 pread64(13, "\22\0\0\0O\2m\0\2\0\0\0\0\0\0\0\3\0\0\0(\0|\4\1\5\370?"..., 16384, 32768) = 16384 write(2, "entry_decode: \"o=test"..., 40) = 40 write(2, "<= entry_decode(o=test"..., 41) = 41 write(2, "=> bdb_entry_get: found entry: \""..., 57) = 57 write(2, "bdb_entry_get: rc=0\n", 20) = 20 mmap2(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb5bc2000 mprotect(0xb5bc2000, 4096, PROT_NONE) = 0 clone(child_stack=0xb63c24d4, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0xb63c2be8, {entry_number:6, base_addr:0xb63c2ba0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0xb63c2be8) = 374 futex(0xb63c2be8, FUTEX_WAIT, 374, NULL) = 0 write(2, "slapd starting\n", 15) = 15 mmap2(NULL, 385024, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb5363000 clone(child_stack=0xb63c24d4, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0xb63c2be8, {entry_number:6, base_addr:0xb63c2ba0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0xb63c2be8) = 375 futex(0xb63c2be8, FUTEX_WAIT, 375, NULL) = 0 +++ killed by SIGSEGV +++ ---- end of tail -70 slapd-strace.log using a wrong ldap password at "Enter LDAP Password:" when promped by "ldappasswd" does not crash the server.

1 0

Re: (ITS#4959) replica seg faults if syncrepl searchbase =""
by ando＠sys-net.it 15 May '07

15 May '07

ando(a)sys-net.it wrote: > this might be pointless. HEAD evolved quite a bit since 2.2.4alpha, so Of course, I meant 2.4.4alpha. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4959) replica seg faults if syncrepl searchbase =""
by ando＠sys-net.it 15 May '07

15 May '07

ali.pouya(a)free.fr wrote: > Hi Pierangelo; > Sorry for the stripped code. > Below you find a backtrace of slapd 2.4.4alpha with the non-stripped code : > > (gdb) bt > #0 0x00889d5a in strcmp () from /lib/tls/libc.so.6 > #1 0x08068ede in select_backend (dn=0xa2f4df5c, manageDSAit=0, noSubs=0) > at backend.c:684 you should print the contents of the "dn" arg to select_backend(), but this might be pointless. HEAD evolved quite a bit since 2.2.4alpha, so I suggested you to check with HEAD code before chasing an already fixed bug. Can you do that? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4959) replica seg faults if syncrepl searchbase =""
by ali.pouya＠free.fr 15 May '07

15 May '07

Hi Pierangelo; Sorry for the stripped code. Below you find a backtrace of slapd 2.4.4alpha with the non-stripped code : (gdb) bt #0 0x00889d5a in strcmp () from /lib/tls/libc.so.6 #1 0x08068ede in select_backend (dn=0xa2f4df5c, manageDSAit=0, noSubs=0) at backend.c:684 #2 0x0806a8ac in fe_aux_operational (op=0xa2f4df40, rs=0xa2f4de80) at backend.c:1779 #3 0x0806a01b in backend_operational (op=0xa2f4df40, rs=0xa2f4de80) at backend.c:1801 #4 0x080a7d06 in do_syncrepl (ctx=0xa2f4e2a0, arg=0x8695fb0) at syncrepl.c:547 #5 0x081281cb in ldap_int_thread_pool_wrapper (xpool=0x865ad78) at tpool.c:704 #6 0x00bb6371 in start_thread () from /lib/tls/libpthread.so.0 #7 0x008e8ffe in clone () from /lib/tls/libc.so.6 (gdb) > Likely because you used a stripped binary. Can you reproduce the issue >with a non-stripped build of HEAD? > >p.

1 0

Re: (ITS#4959) replica seg faults if syncrepl searchbase =""
by ando＠sys-net.it 15 May '07

15 May '07

ali.pouya(a)free.fr wrote: > Full_Name: Ali Pouya > Version: 2.4.4alpha > OS: Linux RedHat AS4 (kernel 2.6) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (145.242.3.30) > > > I'm testing OpenLdap 2.4.4alpha for future use. > I have a master and a replica. > In the replica's syncrepl configuration has searchbase="" then the replica seg > faults after connecting to the master. > > The core backtrace shows very little information : Likely because you used a stripped binary. Can you reproduce the issue with a non-stripped build of HEAD? p. > (gdb) bt > #0 0x00179d5a in strcmp () from /lib/tls/libc.so.6 > #1 0x08068ede in ?? () > #2 0x098c0d50 in ?? () > #3 0x00000000 in ?? () > (gdb) > > Below I add the end of the slapd detailed log. > I can send any other information required. > Thanks and best regards > Ali Pouya > > Log extract : > > ** ld 0x991dcf8 Outstanding Requests: > * msgid 1, origid 1, status InProgress > outstanding referrals 0, parent count 0 > ld 0x991dcf8 request count 1 (abandoned 0) > ** ld 0x991dcf8 Response Queue: > Empty > ld 0x991dcf8 response count 0 > ldap_chkResponseList ld 0x991dcf8 msgid 1 all 1 > ldap_chkResponseList returns ld 0x991dcf8 NULL > ldap_int_select > read1msg: ld 0x991dcf8 msgid 1 all 1 > ber_get_next > ldap_read: want=8, got=8 > 0000: 30 0c 02 01 01 61 07 0a 0....a.. > ldap_read: want=6, got=6 > 0000: 01 00 04 00 04 00 ...... > ber_get_next: tag 0x30 len 12 contents: > ber_dump: buf=0x099270b8 ptr=0x099270b8 end=0x099270c4 len=12 > 0000: 02 01 01 61 07 0a 01 00 04 00 04 00 ...a........ > read1msg: ld 0x991dcf8 msgid 1 message type bind > ber_scanf fmt ({eAA) ber: > ber_dump: buf=0x099270b8 ptr=0x099270bb end=0x099270c4 len=9 > 0000: 61 07 0a 01 00 04 00 04 00 a........ > read1msg: ld 0x991dcf8 0 new referrals > read1msg: mark request completed, ld 0x991dcf8 msgid 1 > request done: ld 0x991dcf8 msgid 1 > res_errno: 0, res_error: <>, res_matched: <> > ldap_free_request (origid 1, msgid 1) > ldap_free_connection 0 1 > ldap_free_connection: refcnt 1 > ldap_parse_result > ber_scanf fmt ({iAA) ber: > ber_dump: buf=0x099270b8 ptr=0x099270bb end=0x099270c4 len=9 > 0000: 61 07 0a 01 00 04 00 04 00 a........ > ber_scanf fmt (}) ber: > ber_dump: buf=0x099270b8 ptr=0x099270c4 end=0x099270c4 len=0 > > ldap_msgfree > Erreur de segmentation (core dumped) > > > > > > > > Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4960) the memory increase quickly and not can be released sometime.
by ando＠sys-net.it 15 May '07

15 May '07

h.b.furuseth(a)usit.uio.no wrote: > hoverwf(a)126.com writes: >> when i disable the code which get the attribute value of entry, >> in other word, both the for loop. this problem seems disappeared, > > Yes. Add ldap_memfree(a); to your inner loop, like > 'man ldap_first_attribute' says: > > NOTES > The ldap_first_attribute() and ldap_next_attribute() > return dynamically allocated memory that must be > freed by the caller via ldap_memfree(3). > > This ITS will be closed. This ITS shouldn't have been opened. Bugs appearing from custom code are 99.9% of the times related to bugs in custom code. Discussion about libldap use does not belong to OpenLDAP, unless it addresses something specific to OpenLDAP's implementation. In any case, this discussion should at most take place on the OpenLDAP-software mailing list. An ITS shouldn't be opened until there is a clear evidence of a bug or an issue with OpenLDAP software. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4960) the memory increase quickly and not can be released sometime.
by h.b.furuseth＠usit.uio.no 15 May '07

15 May '07

hoverwf(a)126.com writes: > when i disable the code which get the attribute value of entry, > in other word, both the for loop. this problem seems disappeared, Yes. Add ldap_memfree(a); to your inner loop, like 'man ldap_first_attribute' says: NOTES The ldap_first_attribute() and ldap_next_attribute() return dynamically allocated memory that must be freed by the caller via ldap_memfree(3). This ITS will be closed. -- Regards, Hallvard

1 0

Re: Re: (ITS#4960) the memory increase qu ickly and not can be released sometime.
by hoverwf＠126.com 15 May '07

15 May '07

--Boundary-=_xtKUzFltSgmOFoknxqwrawgJMmQz Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit NOTE 1: i comment the code in the inner for loop of attribute. NOTE 2: the output of valgrind shows: 62,130 bytes in 6,013 blocks are definitely lost in loss record 10 of 10 at 0x401B704: malloc (vg_replace_malloc.c:149) by 0x4441987: ber_memalloc_x (in /usr/lib/liblber-2.3.so.0.2.9) by 0x443ECA6: ber_get_stringbv (in /usr/lib/liblber-2.3.so.0.2.9) by 0x443ED1E: ber_get_stringa (in /usr/lib/liblber-2.3.so.0.2.9) by 0x443F3EE: ber_scanf (in /usr/lib/liblber-2.3.so.0.2.9) by 0x4161C67: ldap_next_attribute (in /usr/lib/libldap-2.3.so.0.2.9) by 0x80AC0E0: search_node_bydn (myprogram.c:1744) --Boundary-=_xtKUzFltSgmOFoknxqwrawgJMmQz Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable <DIV> </DIV> <DIV>NOTE 1:  i comment the code in the inner for loop of attribute.= </DIV> <DIV>NOTE 2: the output of valgrind shows:</DIV> <DIV> </DIV> <DIV> 62,130 bytes in 6,013 blocks are definitely lost in loss recor= d 10 of 10<BR>         &nbsp= ; at 0x401B704: malloc (vg_replace_malloc.c:149)<BR>   &nb= sp;      by 0x4441987: ber_memalloc_x (in /usr/l= ib/liblber-2.3.so.0.2.9)<BR>       &nb= sp;  by 0x443ECA6: ber_get_stringbv (in /usr/lib/liblber-2.3.so.0.2.= 9)<BR>          by 0x443ED1E= : ber_get_stringa (in /usr/lib/liblber-2.3.so.0.2.9)<BR>  &nbsp= ;       by 0x443F3EE: ber_scanf (in /usr/li= b/liblber-2.3.so.0.2.9)<BR>       &nbs= p;  by 0x4161C67: ldap_next_attribute (in /usr/lib/libldap-2.3.so.0.= 2.9)<BR>          by 0x80AC0= E0: search_node_bydn (myprogram.c:1744)</DIV><br><br><hr> <a style=3D"font-size:14px;line-height:15px; color:#000; text-decoration:= none" href=3D"http://event.mail.163.com/chanel/xyq.htm?from=3D126" target= =3D"_blank"><span style=3D"text-decoration:underline; color:blue">=C3=E2=B7= =D1=CA=D4=CD=E62006=D6=D0=B9=FA=D7=EE=BC=D1=CD=F8=C2=E7=D3=CE=CF=B7--=C3=CE= =BB=C3=CE=F7=D3=CE </span> </a> --Boundary-=_xtKUzFltSgmOFoknxqwrawgJMmQz--

1 0

Re: Re: (ITS#4960) the memory increase qu ickly and not can be released sometime.
by hoverwf＠126.com 15 May '07

15 May '07

--Boundary-=_SZaDxDIRyRIDxknkKcOniAdrRNpg Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable more infomation: =20 =20 NOTE 1: i comment the code in the inner for loop of attribute. =20 NOTE 2: the output of valgrind shows: =3D=3D879=3D=3D=20 =3D=3D879=3D=3D 62,130 bytes in 6,013 blocks are definitely lost in loss = record 10 of 10 =3D=3D879=3D=3D at 0x401B704: malloc (vg_replace_malloc.c:149) =3D=3D879=3D=3D by 0x4441987: ber_memalloc_x (in /usr/lib/liblber-2.3.= so.0.2.9) =3D=3D879=3D=3D by 0x443ECA6: ber_get_stringbv (in /usr/lib/liblber-2.= 3.so.0.2.9) =3D=3D879=3D=3D by 0x443ED1E: ber_get_stringa (in /usr/lib/liblber-2.3= =2Eso.0.2.9) =3D=3D879=3D=3D by 0x443F3EE: ber_scanf (in /usr/lib/liblber-2.3.so.0.= 2.9) =3D=3D879=3D=3D by 0x4161C67: ldap_next_attribute (in /usr/lib/libldap= -2.3.so.0.2.9) =3D=3D879=3D=3D by 0x80AC0E0: search_node_bydn (myprogram.c:1744) =20 =20 =20 =20 =D4=DA2007-05-14=A3=ACopenldap-its(a)openldap.org =D0=B4=B5=C0=A3=BA *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#4960. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its(a)openldap.org with (ITS#4960) in the subject will automatically be attached to the issue report. =09mailto:openldap-its@openldap.org?subject=3D(ITS#4960) You may follow the progress of this report by loading the following URL in a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=3D4960 Please remember to retain your issue tracking number (ITS#4960) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. =09http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2006 The OpenLDAP Foundation, All Rights Reserved. --Boundary-=_SZaDxDIRyRIDxknkKcOniAdrRNpg Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable <DIV>more infomation:</DIV> <DIV> </DIV> <DIV> </DIV> <DIV>NOTE 1:  i comment the code in the inner for loop of attribute.= </DIV> <DIV> </DIV> <DIV>NOTE 2: the output of valgrind shows:</DIV> <DIV>=3D=3D879=3D=3D <BR>=3D=3D879=3D=3D 62,130 bytes in 6,013 blocks are= definitely lost in loss record 10 of 10<BR>=3D=3D879=3D=3D  &n= bsp; at 0x401B704: malloc (vg_replace_malloc.c:149)<BR>=3D=3D879=3D=3D&nb= sp;   by 0x4441987: ber_memalloc_x (in /usr/lib/liblber-2.3.so.= 0.2.9)<BR>=3D=3D879=3D=3D    by 0x443ECA6: ber_get_stringb= v (in /usr/lib/liblber-2.3.so.0.2.9)<BR>=3D=3D879=3D=3D   = by 0x443ED1E: ber_get_stringa (in /usr/lib/liblber-2.3.so.0.2.9)<BR>=3D=3D= 879=3D=3D    by 0x443F3EE: ber_scanf (in /usr/lib/liblber-= 2.3.so.0.2.9)<BR>=3D=3D879=3D=3D    by 0x4161C67: ldap_nex= t_attribute (in /usr/lib/libldap-2.3.so.0.2.9)<BR>=3D=3D879=3D=3D &n= bsp;  by 0x80AC0E0: search_node_bydn (myprogram.c:1744)</DIV> <DIV><BR> </DIV> <DIV> </DIV> <DIV> </DIV> <DIV> </DIV> <DIV ></DIV><BR>=D4=DA2007-05-14=A3=ACopenldap-its(a)openldap.org =D0=B4=B5= =C0=A3=BA<BR> <BLOCKQUOTE style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER= -LEFT: #ccc 1px solid"><PRE style=3D"WORD-WRAP: break-word">*** THIS IS A= N AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#4960. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its(a)openldap.org with (ITS#4960) in the subject will automatically be attached to the issue report. =09<A href=3D"mailto:openldap-its@openldap.org?subject=3D" target=3D_new>= mailto:openldap-its@openldap.org?subject=3D</A>(ITS#4960) You may follow the progress of this report by loading the following URL in a web browser: <A href=3D"http://www.openldap.org/its/index.cgi?findid=3D4960" targe= t=3D_new>http://www.OpenLDAP.org/its/index.cgi?findid=3D4960</A> Please remember to retain your issue tracking number (ITS#4960) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. =09<A href=3D"http://www.openldap.org/support/" target=3D_new>http://www.= OpenLDAP.org/support/</A> -------------- Copyright 1998-2006 The OpenLDAP Foundation, All Rights Reserved. </PRE></BLOCKQUOTE><br><br><hr> <a style=3D"font-size:14px;line-height:15px; color:#000; text-decoration:= none" href=3D"http://event.mail.163.com/chanel/xyq.htm?from=3D126" target= =3D"_blank"><span style=3D"text-decoration:underline; color:blue">=C3=E2=B7= =D1=CA=D4=CD=E62006=D6=D0=B9=FA=D7=EE=BC=D1=CD=F8=C2=E7=D3=CE=CF=B7--=C3=CE= =BB=C3=CE=F7=D3=CE </span> </a> --Boundary-=_SZaDxDIRyRIDxknkKcOniAdrRNpg--

1 0

(ITS#4963) Sub-second ldap_search timeout accuracy
by cs＠unc.edu 14 May '07

14 May '07

Full_Name: Christian Schlatter Version: CVS HEAD (Mon May 14 15:21:36 EDT 2007) OS: ubuntu dapper URL: http://www.unc.edu/~cschlatt/openldap/result.patch Submission from: (NULL) (152.2.199.72) I'm developing an LDAP module for the OpenSER SIP server using OpenLDAP libldap. Since this is a real-time application I need to be able to set LDAP timeouts to a value less than a second. This isn't possible with the existing libldap ldap_result(...timeout...) implementation. In particular, the timeout check at the end of function wait4msg(..) in result.c only has an accuracy of one second. This lead to unexpected behavior for timeout values that are less than a second. I've added a patch for your consideration that adds sub-second accuracy to wait4msg. The code works for me but I don't have experience with the OpenLDAP source code and any coding guidelines. Nevertheless, I'd be very glad if this functionality could be incorporated in a future OpenLDAP release. Christian

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs