openldap-bugs

openldap-bugs@openldap.org

21001 discussions

(ITS#6078)
by frank.offermanns＠caseris.de 05 May '09

05 May '09

Dies ist eine mehrteilige Nachricht im MIME-Format. --=_related 003F71BDC12575AD_= Content-Type: multipart/alternative; boundary="=_alternative 003F71C0C12575AD_=" --=_alternative 003F71C0C12575AD_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hello, i want to add, that with a "bdb" backend the slapd.exe does not crash.=20 Only with the "hdb" backend it crashes.=20 Here is the callstack for this crash:=20 *----> Stack Back Trace <----* WARNING: Stack unwind information not available. Following frames may be=20 wrong. ChildEBP RetAddr Args to Child=20 0d4af720 00497758 00000034 0d4af798 0d4af740=20 slapd!ldap=5Fpvt=5Fthread=5Fmutex=5Flock+0x12 0d4af750 00497b4c 00000000 0d4af798 00000001 slapd!hdb=5Fcache=5Fmodify+0x98 0d4af7c0 0049809f 00c723d0 01204440 09dbcb00 slapd!hdb=5Fcache=5Fmodify+0x4= 8c 0d4af860 004a86d8 0a7391d0 01204440 0000242b slapd!hdb=5Fcache=5Ffind=5Fid+= 0x30f 0d56faf0 0041918b 0a7391d0 0d56fcd8 00000000 slapd!hdb=5Fsearch+0x1538 0d56fb30 004188fd 0a7391d0 0d56fcd8 00000001 slapd!fe=5Fop=5Fsearch+0x43b 0d56fc90 004172c8 0a7391d0 0d56fcd8 0d56fcd4 slapd!do=5Fsearch+0x4ad 0d56fd30 00417ad9 0d56fdd8 0a7391d0 00000000 slapd!connection=5Fhangup+0x5d8 0d56fdb0 004ef6db 0d56fdd8 00000003 00000038 slapd!connection=5Fhangup+0xde9 0d56ff80 77c0a3b0 00bf8bc0 0000077c 000008b8=20 slapd!ldap=5Fpvt=5Fthread=5Fpool=5Fcontext=5Freset+0x1ab 0d56ffb4 7c80b699 00cc66f0 0000077c 000008b8 msvcrt!endthreadex+0xa9 0d56ffec 00000000 77c0a341 00cc66f0 00000000=20 kernel32!GetModuleFileNameA+0x1ba Regards, Frank Offermanns -- -- Frank Offermanns | Entwicklung | CASERIS GmbH=20 Fon: +49 2402 7654-566 Fax: +49 2402 7654-8566 | E-Mail: Frank.Offermanns(a)caseris.com=20 -- CASERIS GmbH | Am Birkenfeld 1-3 | D-52222 Stolberg Gesch=E4ftsf=FChrer Dipl.-Ing. Stefan Preu=DF | Registergericht: Amtsgerich= t=20 Aachen, HRB 14758 --=_alternative 003F71C0C12575AD_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hello, i want to add, that with a "bdb= " backend the slapd.exe does not crash. Only with the "hdb" backend it crashes. Here is the callstack for this crash: *----> Stack Back Trace <----*= WARNING: Stack unwind information not available. Following frames may be wrong. ChildEBP RetAddr  Args to Child               0d4af720 00497758 00000034 0d4af798 0d4af740 slapd!ldap=5Fpvt=5Fthread=5Fmutex=5Flock+0x12 0d4af750 00497b4c 00000000 0d4af798 00000001 slapd!hdb=5Fcache=5Fmodify+0x98 0d4af7c0 0049809f 00c723d0 01204440 09dbcb00 slapd!hdb=5Fcache=5Fmodify+0x48c 0d4af860 004a86d8 0a7391d0 01204440 0000242b slapd!hdb=5Fcache=5Ffind=5Fid+0x30f 0d56faf0 0041918b 0a7391d0 0d56fcd8 00000000 slapd!hdb=5Fsearch+0x1538 0d56fb30 004188fd 0a7391d0 0d56fcd8 00000001 slapd!fe=5Fop=5Fsearch+0x43b 0d56fc90 004172c8 0a7391d0 0d56fcd8 0d56fcd4 slapd!do=5Fsearch+0x4ad 0d56fd30 00417ad9 0d56fdd8 0a7391d0 00000000 slapd!connection=5Fhangup+0x5d8 0d56fdb0 004ef6db 0d56fdd8 00000003 00000038 slapd!connection=5Fhangup+0xde9 0d56ff80 77c0a3b0 00bf8bc0 0000077c 000008b8 slapd!ldap=5Fpvt=5Fthread=5Fpool=5Fcontext=5Freset+0x1ab 0d56ffb4 7c80b699 00cc66f0 0000077c 000008b8 msvcrt!endthreadex+0xa9 0d56ffec 00000000 77c0a341 00cc66f0 00000000 kernel32!GetModuleFileNameA+0x1ba Regards, Frank Offermanns -- <img src=3Dcid:=5F1=5F07180E7C0717F31C003F71AAC12575AD alt=3D"CASERIS G= mbH"> -- Frank Offermanns | Entw= icklung | <a href=3Dhttp://www.caseris.de/>CASERIS GmbH</a> Fon: +49 2402 7654-566<= /font> Fax: +49 2402 7654-8566= | E-Mail: <a href=3Dmailto:Frank.Offermanns@caseris.com>Frank.Offermanns(a)caseris.com</= a> -- CASERIS GmbH | Am Birke= nfeld 1-3 | D-52222 Stolberg Gesch=E4ftsf=FChrer Dip= l.-Ing. Stefan Preu=DF | Registergericht: Amtsgericht Aachen, HRB 14758 --=_alternative 003F71C0C12575AD_=-- --=_related 003F71BDC12575AD_= Content-Type: image/gif Content-ID: <_1_07180E7C0717F31C003F71AAC12575AD> Content-Transfer-Encoding: base64 R0lGODlhiQAaAOYAABcUEaKhoF9dWzo3NMzMzABDg4WEgn2r0CEeG729vNbm8CN4rXVzcU5LSZmZ mc3a5ysoJpG81rGwr2ZmZsbFxERCQH17eo2Miuvr6llXVRkWE73U53yev9bW1d7e3auqqYaw1DMz M7a1tCYjIIKBf6i/1ZORkFRSUEpIRUA9O3BubObm5nh3dRwaF+Xu9oChwTEvLGZmZomHhid7r4B+ fFdVUqmnpiQhHnJwbrW1rdPa5sLBwKbF37q5uFxaWB4bGObe3pnD26Cfnnl4dk1KSCgmI0I/PS8s KZGPjil7tT07OPDv7+70+UdFQt7W1oyMhKalpNTf6mNgXq6trM7e5ou01VFPTcXFvTCAsr29tZmZ mcvg7ZS93sTZ6qrA1tbe7////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5 BAUUAGAALAAAAACJABoAAAf/gGCCgzsqJwg3AkIrg42NHRKRjpMdJjUILVYCUB6TO5GgoaEdYCui oRQdjI6QEgSOHg4ZNwANPgGdk7q7vIJCRCMAwsItIUOruigIyx+7HipHLcPCPzAqpIPKy9vc2xZg Et3cIxAhJw6NBsssgys4MNLTLUcTr733uisV0/zCIyK6PkwboIsALXn9TAxK0a+hCjBTGjasMIiE MByCnEDgF2/aBXwgBS0ZMCyEAREECHyYoKFlC2yNSLaAIczGJCPCihig4GFFhwQWggkDCAYnAAEk aChduhRgRAAhHEidaoCFUQAyBFkEgBHMCWE3aOzo+ZPERmEBQuLbCoBGQZoA/5o4siFMAAFhBBt5 IGbP0QqGAHwIMkoB39MGvFQIkwtmK0YMPwBo2KELQwNhiNXy8nBE2AReHWAcgQATTAhhCcBcBmBz UAe+uwjQ6GuUaK+nKHjtEAZD60UwQFpOdmahsGZeQ1r+AHI8gDCKYHoIS+HoLAIVHwgg02U09b2n RHg5mO6bqyCSAFpMgKL9uOYii92fBmC7iTAJjaD0q9aAgZDSRQljRA0nFGjgCQIM8pQRHjTooAcE mCDUN439BoYI/cxEhAoOAOieI8MkqNlTSjQigTAlNvLBfBJZYVyAEg2DgSBPxTjMETNWaJ4gPaAn EQrefVidMIJppoRktglChP8wU0wiwhANwIBAQ94ZdcQAWGaJZQVL0GjjMDXkomNXgyRAgxUhTNlP k0I2IoUwIWgmUHoTqGCnnfsAAN0uGHQgggz24TXYUIbxhgQSFyBBwzANbDcmL32KcMFqABTRZiM7 HBSkLjXAAAMUYPhoo20EeDiICcMwV1uhtTgiAzH4NeKYa6YKAkU8fV2aAZyODoLEMCtg+OVzYDhw 5ABd6rJEPIwY1QOruTnyFQA/lDZrADhB0OsgQuXa5l28JQmcYp6FKowMDz7YAXwAUFCjEptmNG1v MIqrC26TYHBWXuVhdCKc9nrwJgAjXOoIqiUJYIEKRHRE0FMQ9LJVbgxMA4P/D0PQoAIKGgyTFoxF eCryyEdkAI4w0TqymzBSVCQMA+UJUzILGjc8DBIGO/LBWRL5MKNQWfGywjAAmXCQRC3gLAiLNvY2 Z4qTGDBM0EOUK0gA7MboVs6OYOBAA0XEg8AAKlAGBgEnZCBFjryYkEEGQa8gyxE/uDRCBQaICcYQ Gfjg99+A+5DBEGBQ8PbWurDQdwaMQPE2OoMsIYQPMPwgTQs3pEBDrVwL4pMHbHfuuQeqiG76CkCo kqzprLfu+uuvM/HA7LODwYQCuONuuwu88z7Iiyu8KIgHqX0gBKi8JNmDAQYg/zoU2w4y4wrOc11C Adhjr0MQC3S/wAxg8HDA//gHgDAImQk8BAYG06eUAQFEYbAdIzAL4kA9HRhQ/xLze746BsmKXikE IYIZ8a8dqyABBVbwrFKsboDu8UL2tMc972EhfOQ7QBUGQaHCnUQFMlDBIgJAAiuIAGdIIIEFDFC4 CZCABF3BgMkGIYRi0YxwBsiYCkxAggn0gAAqMIAUDCCDIaCLhWAIgAQs8EIpxEJuDKDBEDBwARIY AAkEqIEFJFDDjLEAHUMwAAmucRwJTnB73lvABcVHvg0KooMUkIEJCAcGFfSgQySoIxQm0CAf2IAB jCDADDugPkKoTwj3e5YDHoIBEX5jBeEBwwRsoL4LCCFMF0KCAUxQP5QkgP90NShWg4Zggo+xQAQ1 mFEArFDGCRYAjRbEYBsH8RlB7EAGDoiVDEQgBAJ8gwUyYEEkoDCFDrIDDEuYoSDkiDwPqLATNlAI GPwDEAzkcW8BoKMJhHBMAjjgAiyooSA6QAMTSOAhJmiQBYaQiwAkShAS4FdIzJg9NM7gnmvMoBvB cAEaQMguJmgGGE7Sy2+ogADs9IAMVmCAD8RCmQE4aP4cgIEJpIIBO2BBJ6CAsyUwIABNWgGFMHqN DjQACvXzJgnSl4pyPqQDNagEFCggliE4gQI4yB+NqKOZKHDgBUDlgAu2EIGiRiAIYPjCBpa6gS40 QgA3GAE6bGA2GxCgBx5LqOFHRIAlomQAAjJojf0gAFZBEGAAMKihCRiRADY5oAeFWcLHTLCEKSCg ARfYAeQ8wMslnBUGTWLBACbgzg6coJTFCoESXiFOnAYCADs= --=_related 003F71BDC12575AD_=--

1 0

Re: (ITS#6077) Spurious uniqueness errors with filters in unique overlays
by masarati＠aero.polimi.it 05 May '09

05 May '09

andres(a)anarazel.de wrote: > This is a multi-part message in MIME format. > --------------080405020304060402030808 > Content-Type: text/plain; charset=UTF-8; format=flowed > Content-Transfer-Encoding: 7bit Your analysis looks correct. In fact, the uniqueness check for add seems to assume that the current entry will implicitly match the uniqueness filter, which may not be the case if an additional filter is provided within the URI. > Fixing this for unique_add seams easy enough (see preliminary attached > patch) - fixing it for modrdn/modify seems to be another difficulty > level as in order to properly apply the filter I think the full > modifications have to be applied... > > If wanted I can produce a patch for this as well, but I would like to > know if that is appreciated and if my plan for fixing looks sensible: > - Pull the "modification simulation" code out of constraint.c (line > 959:1040 and some more in 2.4.16) into constraints.c > - Add a overlay-int.h > - Make constraint.c and unique.c use that > > As I dont really know the openldap codebase my analysis could be > completely wrong - I would appreciate some feedback. Yes, the code provided in the constraint overlay is exactly intended to simulate the modification in order to be able to assess the consistency of the resulting entry with the constraint. What you suggest sounds reasonable; a patch would definitely be welcome. The code extracted from constraint.c should probably be placed in slapd, and always built since other portions of slapd might need it in the future. Please note that overlays can be selectively built, or even built as modules, so creating cross-dependences is not a good idea IMHO. p.

1 0

(ITS#6094) test054 doesn't replicate an entry
by dieter＠dkluenter.de 05 May '09

05 May '09

Full_Name: Dieter Kluenter Version: 2.4.16 OS: Linux x86_64 URL: http://dkluenter.de/download/dkluenter_test054.tgz Submission from: (NULL) (87.154.44.82) test054 doesn't replicate the entry dn: ou=Information Technolgy Devision,ou=people,dc=example,dc=com A tar archive containing the files server1.flt, server2.flt, server1.log, server4.log can be downloaded from the below URL -Dieter

1 0

Re: (ITS#6092) correct string problem in guess_service_principal()
by mikbec＠web.de 04 May '09

04 May '09

Hallvard B Furuseth wrote: > mikbec(a)web.de writes: >> When GSSAPI option GSSAPI_ALLOW_REMOTE_PRINCIPAL is switched on then >> string provided by "givenstr" will be used as principal name. But >> length of string counted in "svc_principal_size" is one letter to >> less. > > svc_principal_size looks correct in that case, but the snprintf is > wrong. I can't test, but it should work to pass svc_principal_size > instead of svc_principal_size-1. Except snprintf seems pointless here, > since we already make sure to allocate enough memory to avoid overflow. Your code looks OK to me ... so there is no need for any code that relates to "svc_principal_size" any more. > > I'll take the opportunity to get rid of a gcc -Wformat warning - it > can't verify the format argument since that is not a string literal. > > Like this. What's a good name for my new "prefix" variable below? I > don't know Kerberos/GSSAPI terminology. Hmmm ... its a good question. The problem is here the hostname is the instance and "ldap/" is the service we are looking for on that host. So "prefix" is really the "service" and "dnsHostName" or "host" are the service instances .... I think if we call it "spn_instance_prefix" or simply "svc_prefix" then this will be a good choice. Please have a look at: http://www.gnu.org/software/shishi/manual/html_node/Realm-and-Principal-Nam… section 4.3.2 Principal Names. This is a summary of RFC 1510 chapter 7.2 "Principal names". The princial name type we are using here is mostly NT-SRV-HST. > > const char *prefix; > ... > if (allow_remote && givenstr) { > prefix = ""; > str = givenstr; > } else { > prefix = "ldap/"; > str = (allow_remote && dnsHostName) ? dnsHostName : host; > } > > svc_principal = (char*) ldap_memalloc(strlen(prefix) + strlen(str) + 1); > if ( svc_principal == NULL ) { > ld->ld_errno = LDAP_NO_MEMORY; > return ld->ld_errno; > } > sprintf( svc_principal, "%s%s", prefix, str); >

1 0

Re: (ITS#6092) correct string problem in guess_service_principal()
by h.b.furuseth＠usit.uio.no 04 May '09

04 May '09

mikbec(a)web.de writes: > When GSSAPI option GSSAPI_ALLOW_REMOTE_PRINCIPAL is switched on then > string provided by "givenstr" will be used as principal name. But > length of string counted in "svc_principal_size" is one letter to > less. svc_principal_size looks correct in that case, but the snprintf is wrong. I can't test, but it should work to pass svc_principal_size instead of svc_principal_size-1. Except snprintf seems pointless here, since we already make sure to allocate enough memory to avoid overflow. I'll take the opportunity to get rid of a gcc -Wformat warning - it can't verify the format argument since that is not a string literal. Like this. What's a good name for my new "prefix" variable below? I don't know Kerberos/GSSAPI terminology. const char *prefix; ... if (allow_remote && givenstr) { prefix = ""; str = givenstr; } else { prefix = "ldap/"; str = (allow_remote && dnsHostName) ? dnsHostName : host; } svc_principal = (char*) ldap_memalloc(strlen(prefix) + strlen(str) + 1); if ( svc_principal == NULL ) { ld->ld_errno = LDAP_NO_MEMORY; return ld->ld_errno; } sprintf( svc_principal, "%s%s", prefix, str); -- Hallvard

1 0

(ITS#6093) correct hostname resolving problem in guess_service_principal()
by mikbec＠web.de 04 May '09

04 May '09

Full_Name: Mike Becher Version: HEAD of 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/mike-becher-090504.libraries-libldap.patch Submission from: (NULL) (84.150.168.64) patch file name: mike-becher-090504.libraries-libldap.patch patch subject: correct hostname resolving problem in guess_service_principal() patch description: In AD (Active Directory) enviroment this patch removes the problem with potentially invalid hostname "DomainDnsZones.MY.DOMAIN" which might be given in the "host" string. Instead (if possible) hostname of AD-DC will be tried first to which the caller is connected to. It uses function ldap_host_connected_to() provided in os-ip.c to do a reverse lookup on the address to get the official hostname of connected host. This is necessary for kerberos to work right, since the official hostname is used as the kerberos instance.

1 0

(ITS#6092) correct string problem in guess_service_principal()
by mikbec＠web.de 04 May '09

04 May '09

Full_Name: Mike Becher Version: HEAD of 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/mike-becher-090504.libraries-libldap-gssapi… Submission from: (NULL) (84.150.168.64) patch file name: mike-becher-090504.libraries-libldap-gssapi.2.patch patch subject: correct string problem in guess_service_principal() patch description: When GSSAPI option GSSAPI_ALLOW_REMOTE_PRINCIPAL is switched on then string provided by "givenstr" will be used as principal name. But length of string counted in "svc_principal_size" is one letter to less. This patch corrects this problem, allocates memory for one more character to get space for '\0' and sets it.

1 0

(ITS#6091) missing implementation of "switch off" functionality of GSSAPI OPTIONS
by mikbec＠web.de 04 May '09

04 May '09

Full_Name: Mike Becher Version: HEAD of 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/mike-becher-090504.libraries-libldap-gssapi… Submission from: (NULL) (84.150.168.64) patch file name: mike-becher-090504.libraries-libldap-gssapi.1.patch patch subject: missing implementation of "switch off" functionality of GSSAPI OPTIONS patch description: Like manual pages of "ldap.conf (5)" describe in section GSSAPI OPTIONS it should be able to activate and/or deactivate options GSSAPI_SIGN, GSSAPI_ENCRYPT, and GSSAPI_ALLOW_REMOTE_PRINCIPAL. But functionality to switch off such a feature is not implemented. This patch adds the "switch off" functionality.

1 0

Re: (ITS#6084) ppolicy should allow scheduled password expiration
by Guillaume.Rousse＠inria.fr 04 May '09

04 May '09

Howard Chu a écrit : > Since the ppolicy module's behavior is dictated by the Behera draft, any > suggestions for changes in this area should probably first be raised on > the ietf-ldapext mailing list. Right, but openldap implementation already have extension, such pwdCheckModule. Additional extension could be implemented, before getting standardized. Also, the ietf-ldapext seems to be an highly-technical list, and I don't feel confortable enough to post this kind of request directly there. Discussing various limitations of ppolicy among openldap users first would probably allow openldap core team to suggest a more polished extension request themselves. -- BOFH excuse #287: Telecommunications is downshifting.

1 0

Re: (ITS#6090) slapd locks up; all slapd worker threads blocking on mutex acquisition in bdb_cache_lru_link()
by jwm＠horde.net 04 May '09

04 May '09

On Fri, 01 May 2009 15:10:46 -0700, Howard Chu wrote: > It seems you may need to recompile BerkeleyDB with debugging enabled (and > with -fno-omit-frame-pointer) to get a useful trace from this. This is > looking more like a BDB locking issue than an OpenLDAP issue. Done. Now we wait. > If you still have the environment, db_stat -CA would be helpful. slapd has been restarted since, so the lock statistics won't be useful. I've modified our harness to get them automatically with the backtrace. john -- John Morrissey _o /\ ---- __o jwm(a)horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs