- openldap-bugs - openldap.org

(ITS#7360) Patch - Mozilla NSS - accept MozNSS certname in the form of tokenname:certnickname
by rmeggins＠redhat.com 20 Aug '12

20 Aug '12

Full_Name: Rich Megginson Version: master OS: Fedora17 URL: ftp://ftp.openldap.org/incoming/0001-accept-nss-certname-in-the-form-of-tok… Submission from: (NULL) (76.26.104.137) There are cases where the user may want to force the use of a particular PKCS11 device to use for a given certificate. Allow the user to do this with MozNSS by specifying the cert as "tokenname:certnickname" where token name is the name of a token/slot in a PKCS11 device and certnickname is the nickname of a certificate on that device. These patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#7359) [PATCH] MozNSS: prefer unlocked slot when getting private key
by jvcelak＠redhat.com 20 Aug '12

20 Aug '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-20120820-nss-prefer-unlocked-slot-p… Submission from: (NULL) (94.113.220.43) With last MozNSS patches for OpenLDAP, the library explicitly opens the certificate database when retrieving the certificates, even if the database is already opened. (Requried for safe certificate lookup from a nickname.) This might also require a re-authentication to a slot, which holds the private key. Some application might expect that the slot with private key is already unlocked before passing the control to libldap. This got broken with the recent changes. I'm attaching a patch which fixes it. If the certificate (and corresponding key) is held in multiple slots, libldap will take the key from an already authenticated slot. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#7358) Patch to fix Visual Studio build broken by 2.4.32
by mbooth＠apache.org 20 Aug '12

20 Aug '12

Full_Name: Mat Booth Version: 2.4.32 OS: Windows XP URL: http://people.apache.org/~mbooth/0001-Fix-build-error-syntax-error-missing-… Submission from: (NULL) (77.86.30.139) The provided patch fixes a build problem for Visual Studio 2005 that was introduced with OpenLDAP 2.4.32. * libraries/libldap/init.c Use C89-style variable declarations because Visual C does not support C99-style declarations. Avoids a "syntax error : missing ; before type" compile-time error with Microsoft compilers. The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Mat Booth <mbooth(a)apache.org>. I have not assigned rights and/or interest in this work to any party. I, Mat Booth, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#7357) Pass-through radius auth. with RFC2865
by jet＠transniaga.co.th 19 Aug '12

19 Aug '12

Full_Name: Jetasik Anantakunupakorn Version: 2.4.32 OS: FreeBSD 9.0-RELEASE amd64 URL: http://www.openldap.org/lists/openldap-technical/201208/msg00172.html Submission from: (NULL) (58.11.65.20) Pass-through radius authentication in contrib's passwd module(radius.c) does not include either a NAS-IP or a NAS-Identifier, according to radius RFC 2865 one of these attributes is mandatory in the access request. The thing is that the previous version of Radius RFC standard(RFC 2138) specified that the access request "SHOULD" contain either a NAS-IP or a NAS-Identifier but the current version use "MUST" instead.

1 0

Re: (ITS#7340) Regression in slapo-constraint
by michael＠stroeder.com 19 Aug '12

19 Aug '12

quanah(a)zimbra.com wrote: > --On Saturday, August 18, 2012 2:06 PM +0200 Michael Ströder > <michael(a)stroeder.com> wrote: >> I experienced the regression with RE24 but did not test with master yet. >> But if it works with master the porting to RE24 might have been >> incomplete back then. > > Ok. I'll backport it again, with the large test suite it now has as well, > and see what happens. ;) Thanks. After your commits I will test RE24 immediately with my customer's setup and provide an example config if RE24 fails. Ciao, Michael.

1 0

Re: (ITS#7340) Regression in slapo-constraint
by quanah＠zimbra.com 18 Aug '12

18 Aug '12

--On Saturday, August 18, 2012 2:06 PM +0200 Michael Ströder <michael(a)stroeder.com> wrote: > quanah(a)zimbra.com wrote: >> --On Tuesday, July 31, 2012 11:41 AM +0000 jsynacek(a)redhat.com wrote: >>> I'm having hard time reproducing this. Still works for me. >>> >>> Please provide a minimal setup and an example that fails, so I can fix >>> the patch. Thank you. >> >> Have you had any luck in providing a configuration that doesn't work to >> Jan, so this can be resolved? > > I'm currently *very* busy. It's definitely on my TODO list to provide a > test config. > > One question: > Is the patch still enabled in GIT master? > > I experienced the regression with RE24 but did not test with master yet. > But if it works with master the porting to RE24 might have been > incomplete back then. Ok. I'll backport it again, with the large test suite it now has as well, and see what happens. ;) --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#7340) Regression in slapo-constraint
by michael＠stroeder.com 18 Aug '12

18 Aug '12

quanah(a)zimbra.com wrote: > --On Tuesday, July 31, 2012 11:41 AM +0000 jsynacek(a)redhat.com wrote: >> I'm having hard time reproducing this. Still works for me. >> >> Please provide a minimal setup and an example that fails, so I can fix the >> patch. Thank you. > > Have you had any luck in providing a configuration that doesn't work to > Jan, so this can be resolved? I'm currently *very* busy. It's definitely on my TODO list to provide a test config. One question: Is the patch still enabled in GIT master? I experienced the regression with RE24 but did not test with master yet. But if it works with master the porting to RE24 might have been incomplete back then. Ciao, Michael.

1 0

Re: (ITS#7340) Regression in slapo-constraint
by quanah＠zimbra.com 17 Aug '12

17 Aug '12

--On Tuesday, July 31, 2012 11:41 AM +0000 jsynacek(a)redhat.com wrote: > On 07/30/2012 08:38 PM, Michael Str?der wrote: >> Jan Synacek wrote: >>> On 07/27/2012 10:47 PM, michael(a)stroeder.com wrote: >>>> It seems there's a regression in slapo-constraint possibly caused by a >>>> patch for ITS#7168. >>> >>> This works for me: >>> >>> slapd.ldif: >>> ... >>> dn: olcOverlay=constraint,olcDatabase={1}bdb,cn=config >>> objectClass: olcOverlayConfig >>> objectClass: olcConstraintConfig >>> olcOverlay: constraint >>> olcConstraintAttribute: mail count 3 >>> olcConstraintAttribute: description count 2 >>> ... >> >> From the excerpt above it seems you've only added a count constraint. >> >> Please use more features of slapo-constraint for testing, e.g. regex- or >> URL-based constraints. >> >> The patch for ITS#7168 broke all my customer setups since I'm >> slapo-constraint quite heavily. >> >> Ciao, Michael. >> > > I'm having hard time reproducing this. Still works for me. > > Please provide a minimal setup and an example that fails, so I can fix the > patch. Thank you. Hi Michael, Have you had any luck in providing a configuration that doesn't work to Jan, so this can be resolved? Thanks, 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

(ITS#7356) double-free in back-mdb slapadd -q -w
by hyc＠OpenLDAP.org 17 Aug '12

17 Aug '12

Full_Name: Howard Chu Version: 2.4.32 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc slapadd can abort at the end, trying to close a cursor after its owning transaction has already finished. The resulting DB is clean, not corrupted. Fixed in git master commit 11cf13bf9d50259e9990be9ee08506b151e2a907

1 0

Re: (ITS#7354) segfault with delta-syncrepl MMR
by quanah＠zimbra.com 16 Aug '12

16 Aug '12

--On Thursday, August 16, 2012 5:03 PM -0700 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Thursday, August 16, 2012 11:09 PM +0000 quanah(a)zimbra.com wrote: > >> --On Wednesday, August 15, 2012 9:36 PM +0000 quanah(a)zimbra.com wrote: > > Crash occurs with this op: > > Aug 16 16:50:27 zqa-129 slapd[30991]: slap_queue_csn: queing > 0x7fd7d0002b29 20120816203158.675452Z#000000#001#000000 The op immediately following this one is: dn: reqStart=20120816203211.000001Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20120816203211.000001Z reqEnd: 20120816203211.000002Z reqType: modify reqSession: 100 reqAuthzID: cn=config reqDN: cn=zqa-129.eng.vmware.com,cn=servers,cn=zimbra reqResult: 0 reqMod:: emltYnJhU1NMQ2VydGlmaWNhdGU6PSAtLS0tLUJFR0lOIENFUlRJRklDQVRFLS0tLS0KT UlJR3REQ0NCWnlnQXdJQkFnSVFES0xNK0ZiN3JLbnFjM2Zza25oSE1qQU5CZ2txaGtpRzl3MEJBU V VGQURCbQpNUXN3Q1FZRFZRUUdFd0pWVXpFVk1CTUdBMVVFQ2hNTVJHbG5hVU5sY25RZ1NXNWpNUm t 3RndZRFZRUUxFeEIzCmQzY3VaR2xuYVdObGNuUXVZMjl0TVNVd0l3WURWUVFERXh4RWFXZHBRMlZ 5 ZENCSWFXZG9JRUZ6YzNWeVlXNWoKWlNCRFFTMHpNQjRYRFRBNU1URXhOekF3TURBd01Gb1hEVEV5 T VRFeE9USXpOVGsxT1Zvd2FERUxNQWtHQTFVRQpCaE1DVlZNeEV6QVJCZ05WQkFnVENrTmhiR2xtY j NKdWFXRXhFakFRQmdOVkJBY1RDVkJoYkc4Z1FXeDBiekVWCk1CTUdBMVVFQ2hNTVZrMTNZWEpsTE N CSmJtTXVNUmt3RndZRFZRUURGQkFxTG1WdVp5NTJiWGRoY21VdVkyOXQKTUlJQklqQU5CZ2txaGt p Rzl3MEJBUUVGQUFPQ0FROEFNSUlCQ2dLQ0FRRUFwZnBOL2tDSUluZzNNN0QzMjVjMQo3dW0yS1Ba Z 0E1M1U0cHRSdWphSkIra0pYdWVoR0ZZdjlFZStSZTZYczd2K1lQSFdsbzZnV3phR2VES2lIK3lzC m R5SFhValF0OHN5SDhZcnlnTDl4aitCWEFYdGc1SisvdEJPR05ieFYvMlZ3KzEvcU5ZdG5BS25LbF A 4eTlxL2oKd3dOcmdTTzFlemRQUW1KUFJyMTM3WHdnTWEwU0szdVhTRzNQSXU5ZlpwcUh3c2FlbFN B NWRqeUxZUVR4a2RjZAp2RWJzc2NTem84L05iM0VqSWZoS3NxT004RzNjTzBrM3lGM1V2bzFPTlBQ N kJxcDBCN1JiVkxZQ2hoeUZSUCtVCm90L2hHNUpxaks4T2QwWkFPdDd4OGpSb3NBMlFwNm5hQnIzZ n RQdkt5cC9UQ2dNaWdVYzRxSGcxUTZ2aDVxVUoKclFJREFRQUJvNElEV2pDQ0ExWXdId1lEVlIwak J CZ3dGb0FVVU9wemlkc3AreENQbnVVQklOVGVlWmxJZy9jdwpIUVlEVlIwT0JCWUVGRENxM3hmb3N F RzkxRUU3SVVrR3J0SFNBWWFrTUNzR0ExVWRFUVFrTUNLQ0RtVnVaeTUyCmJYZGhjbVV1WTI5dGdo Q XFMbVZ1Wnk1MmJYZGhjbVV1WTI5dE1JSUJ4QVlEVlIwZ0JJSUJ1ekNDQWJjd2dnR3oKQmdsZ2hrZ 0 JodjFzQVFFd2dnR2tNRG9HQ0NzR0FRVUZCd0lCRmk1b2RIUndPaTh2ZDNkM0xtUnBaMmxqWlhKMA p MbU52YlM5emMyd3RZM0J6TFhKbGNHOXphWFJ2Y25rdWFIUnRNSUlCWkFZSUt3WUJCUVVIQWdJd2d n RldIb0lCClVnQkJBRzRBZVFBZ0FIVUFjd0JsQUNBQWJ3Qm1BQ0FBZEFCb0FHa0Fjd0FnQUVNQVpR Q nlBSFFBYVFCbUFHa0EKWXdCaEFIUUFaUUFnQUdNQWJ3QnVBSE1BZEFCcEFIUUFkUUIwQUdVQWN3Q W dBR0VBWXdCakFHVUFjQUIwQUdFQQpiZ0JqQUdVQUlBQnZBR1lBSUFCMEFHZ0FaUUFnQUVRQWFRQm 5 BR2tBUXdCbEFISUFkQUFnQUVNQVVBQXZBRU1BClVBQlRBQ0FBWVFCdUFHUUFJQUIwQUdnQVpRQWd B RklBWlFCc0FIa0FhUUJ1QUdjQUlBQlFBR0VBY2dCMEFIa0EKSUFCQkFHY0FjZ0JsQUdVQWJRQmxB R zRBZEFBZ0FIY0FhQUJwQUdNQWFBQWdBR3dBYVFCdEFHa0FkQUFnQUd3QQphUUJoQUdJQWFRQnNBR 2 tBZEFCNUFDQUFZUUJ1QUdRQUlBQmhBSElBWlFBZ0FHa0FiZ0JqQUc4QWNnQndBRzhBCmNnQmhBSF F BWlFCa0FDQUFhQUJsQUhJQVpRQnBBRzRBSUFCaUFIa0FJQUJ5QUdVQVpnQmxBSElBWlFCdUFHTUE K WlFBdU1Ic0dDQ3NHQVFVRkJ3RUJCRzh3YlRBa0JnZ3JCZ0VGQlFjd0FZWVlhSFIwY0RvdkwyOWpj M 0F1WkdsbgphV05sY25RdVkyOXRNRVVHQ0NzR0FRVUZCekFDaGpsb2RIUndPaTh2WTJGalpYSjBje T VrYVdkcFkyVnlkQzVqCmIyMHZSR2xuYVVObGNuUklhV2RvUVhOemRYSmhibU5sUTBFdE15NWpjbl F 3REFZRFZSMFRBUUgvQkFJd0FEQmwKQmdOVkhSOEVYakJjTUN5Z0txQW9oaVpvZEhSd09pOHZZM0p z TXk1a2FXZHBZMlZ5ZEM1amIyMHZZMkV6TFRJdwpNVEZpTG1OeWJEQXNvQ3FnS0lZbWFIUjBjRG92 T DJOeWJEUXVaR2xuYVdObGNuUXVZMjl0TDJOaE15MHlNREV4CllpNWpjbXd3SFFZRFZSMGxCQll3R k FZSUt3WUJCUVVIQXdFR0NDc0dBUVVGQndNQ01BNEdBMVVkRHdFQi93UUUKQXdJRm9EQU5CZ2txaG t pRzl3MEJBUVVGQUFPQ0FRRUFBQjc0Tk51VThnZFpuRWFHZlE3dm1LRkFVSVdua2h2dwp1eTNQQjV F MmVMWUp1Y2sxUzJESExaMmlPVTZoeWlJWmF4dk9ndmgzbnh6bDIwVlVGdmNMMGIxQkoyUmtiMnk4 C nZ4RHVPY3lJZnVTemRQQnQ3a1djM0RRc21KWStERWlGM25FaEY5WmhJNEJZZVpxYVc2NXBsa2NhT X ZFR2tpVUcKZFRqSVJiV1B3SU1VKzRUMVA5aFlZZVJLeGNhRmowZXJXalJpeDd6MnBwV0d1RlNSMD d aNm43cndFakE2M2pGawp6MFhOMFZFaXZya0dObDBaWEl2OU1pZktQTEI5TDV6S012RHl3dEU0SmV X TWZ1MWpHUUN4azFuWkVYYkd3UFluCnNrSXZQTDZ4Vm1kaWxVcTk3TFh0dTVJeDdtY3hxdXVQZlB2 e WRIMzR3dTlpdE1KNnR0N1dXdz09Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0KCi0tLS0tQkVHS U 4gQ0VSVElGSUNBVEUtLS0tLQpNSUlHdERDQ0JaeWdBd0lCQWdJUURLTE0rRmI3cktucWMzZnNrbm h ITWpBTkJna3Foa2lHOXcwQkFRVUZBREJtCk1Rc3dDUVlEVlFRR0V3SlZVekVWTUJNR0ExVUVDaE1 N UkdsbmFVTmxjblFnU1c1ak1Sa3dGd1lEVlFRTEV4QjMKZDNjdVpHbG5hV05sY25RdVkyOXRNU1V3 S XdZRFZRUURFeHhFYVdkcFEyVnlkQ0JJYVdkb0lFRnpjM1Z5WVc1agpaU0JEUVMwek1CNFhEVEE1T V RFeE56QXdNREF3TUZvWERURXlNVEV4T1RJek5UazFPVm93YURFTE1Ba0dBMVVFCkJoTUNWVk14RX p BUkJnTlZCQWdUQ2tOaGJHbG1iM0p1YVdFeEVqQVFCZ05WQkFjVENWQmhiRzhnUVd4MGJ6RVYKTUJ N R0ExVUVDaE1NVmsxM1lYSmxMQ0JKYm1NdU1Sa3dGd1lEVlFRREZCQXFMbVZ1Wnk1MmJYZGhjbVV1 W TI5dApNSUlCSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQVE4QU1JSUJDZ0tDQVFFQXBmcE4va0NJS W 5nM003RDMyNWMxCjd1bTJLUFpnQTUzVTRwdFJ1amFKQitrSlh1ZWhHRll2OUVlK1JlNlhzN3YrWV B IV2xvNmdXemFHZURLaUgreXMKZHlIWFVqUXQ4c3lIOFlyeWdMOXhqK0JYQVh0ZzVKKy90Qk9HTmJ 4 Vi8yVncrMS9xTll0bkFLbktsUDh5OXEvagp3d05yZ1NPMWV6ZFBRbUpQUnIxMzdYd2dNYTBTSzN1 W FNHM1BJdTlmWnBxSHdzYWVsU0E1ZGp5TFlRVHhrZGNkCnZFYnNzY1N6bzgvTmIzRWpJZmhLc3FPT T hHM2NPMGszeUYzVXZvMU9OUFA2QnFwMEI3UmJWTFlDaGh5RlJQK1UKb3QvaEc1SnFqSzhPZDBaQU 9 0N3g4alJvc0EyUXA2bmFCcjNmdFB2S3lwL1RDZ01pZ1VjNHFIZzFRNnZoNXFVSgpyUUlEQVFBQm8 0 SURXakNDQTFZd0h3WURWUjBqQkJnd0ZvQVVVT3B6aWRzcCt4Q1BudVVCSU5UZWVabElnL2N3CkhR W URWUjBPQkJZRUZEQ3EzeGZvc0VHOTFFRTdJVWtHcnRIU0FZYWtNQ3NHQTFVZEVRUWtNQ0tDRG1Wd V p5NTIKYlhkaGNtVXVZMjl0Z2hBcUxtVnVaeTUyYlhkaGNtVXVZMjl0TUlJQnhBWURWUjBnQklJQn V 6Q0NBYmN3Z2dHegpCZ2xnaGtnQmh2MXNBUUV3Z2dHa01Eb0dDQ3NHQVFVRkJ3SUJGaTVvZEhSd09 p OHZkM2QzTG1ScFoybGpaWEowCkxtTnZiUzl6YzJ3dFkzQnpMWEpsY0c5emFYUnZjbmt1YUhSdE1J S UJaQVlJS3dZQkJRVUhBZ0l3Z2dGV0hvSUIKVWdCQkFHNEFlUUFnQUhVQWN3QmxBQ0FBYndCbUFDQ U FkQUJvQUdrQWN3QWdBRU1BWlFCeUFIUUFhUUJtQUdrQQpZd0JoQUhRQVpRQWdBR01BYndCdUFITU F kQUJwQUhRQWRRQjBBR1VBY3dBZ0FHRUFZd0JqQUdVQWNBQjBBR0VBCmJnQmpBR1VBSUFCdkFHWUF J QUIwQUdnQVpRQWdBRVFBYVFCbkFHa0FRd0JsQUhJQWRBQWdBRU1BVUFBdkFFTUEKVUFCVEFDQUFZ U UJ1QUdRQUlBQjBBR2dBWlFBZ0FGSUFaUUJzQUhrQWFRQnVBR2NBSUFCUUFHRUFjZ0IwQUhrQQpJQ U JCQUdjQWNnQmxBR1VBYlFCbEFHNEFkQUFnQUhjQWFBQnBBR01BYUFBZ0FHd0FhUUJ0QUdrQWRBQW d BR3dBCmFRQmhBR0lBYVFCc0FHa0FkQUI1QUNBQVlRQnVBR1FBSUFCaEFISUFaUUFnQUdrQWJnQmp B RzhBY2dCd0FHOEEKY2dCaEFIUUFaUUJrQUNBQWFBQmxBSElBWlFCcEFHNEFJQUJpQUhrQUlBQnlB R 1VBWmdCbEFISUFaUUJ1QUdNQQpaUUF1TUhzR0NDc0dBUVVGQndFQkJHOHdiVEFrQmdnckJnRUZCU W N3QVlZWWFIUjBjRG92TDI5amMzQXVaR2xuCmFXTmxjblF1WTI5dE1FVUdDQ3NHQVFVRkJ6QUNoam x vZEhSd09pOHZZMkZqWlhKMGN5NWthV2RwWTJWeWRDNWoKYjIwdlJHbG5hVU5sY25SSWFXZG9RWE5 6 ZFhKaGJtTmxRMEV0TXk1amNuUXdEQVlEVlIwVEFRSC9CQUl3QURCbApCZ05WSFI4RVhqQmNNQ3ln S 3FBb2hpWm9kSFJ3T2k4dlkzSnNNeTVrYVdkcFkyVnlkQzVqYjIwdlkyRXpMVEl3Ck1URmlMbU55Y k RBc29DcWdLSVltYUhSMGNEb3ZMMk55YkRRdVpHbG5hV05sY25RdVkyOXRMMk5oTXkweU1ERXgKWW k 1amNtd3dIUVlEVlIwbEJCWXdGQVlJS3dZQkJRVUhBd0VHQ0NzR0FRVUZCd01DTUE0R0ExVWREd0V C L3dRRQpBd0lGb0RBTkJna3Foa2lHOXcwQkFRVUZBQU9DQVFFQUFCNzROTnVVOGdkWm5FYUdmUTd2 b UtGQVVJV25raHZ3CnV5M1BCNUUyZUxZSnVjazFTMkRITFoyaU9VNmh5aUlaYXh2T2d2aDNueHpsM j BWVUZ2Y0wwYjFCSjJSa2IyeTgKdnhEdU9jeUlmdVN6ZFBCdDdrV2MzRFFzbUpZK0RFaUYzbkVoRj l aaEk0QlllWnFhVzY1cGxrY2FNdkVHa2lVRwpkVGpJUmJXUHdJTVUrNFQxUDloWVllUkt4Y2FGajB l cldqUml4N3oycHBXR3VGU1IwN1o2bjdyd0VqQTYzakZrCnowWE4wVkVpdnJrR05sMFpYSXY5TWlm S 1BMQjlMNXpLTXZEeXd0RTRKZVdNZnUxakdRQ3hrMW5aRVhiR3dQWW4Kc2tJdlBMNnhWbWRpbFVxO T dMWHR1NUl4N21jeHF1dVBmUHZ5ZEgzNHd1OWl0TUo2dHQ3V1d3PT0KLS0tLS1FTkQgQ0VSVElGSU N BVEUtLS0tLQotLS0tLUJFR0lOIENFUlRJRklDQVRFLS0tLS0KTUlJRHhUQ0NBcTJnQXdJQkFnSVF B cXhjSm1vTFFKdVBDM255cmtZbGR6QU5CZ2txaGtpRzl3MEJBUVVGQURCcwpNUXN3Q1FZRFZRUUdF d 0pWVXpFVk1CTUdBMVVFQ2hNTVJHbG5hVU5sY25RZ1NXNWpNUmt3RndZRFZRUUxFeEIzCmQzY3VaR 2 xuYVdObGNuUXVZMjl0TVNzd0tRWURWUVFERXlKRWFXZHBRMlZ5ZENCSWFXZG9JRUZ6YzNWeVlXNW o KWlNCRlZpQlNiMjkwSUVOQk1CNFhEVEEyTVRFeE1EQXdNREF3TUZvWERUTXhNVEV4TURBd01EQXd N Rm93YkRFTApNQWtHQTFVRUJoTUNWVk14RlRBVEJnTlZCQW9UREVScFoybERaWEowSUVsdVl6RVpN Q mNHQTFVRUN4TVFkM2QzCkxtUnBaMmxqWlhKMExtTnZiVEVyTUNrR0ExVUVBeE1pUkdsbmFVTmxjb l FnU0dsbmFDQkJjM04xY21GdVkyVWcKUlZZZ1VtOXZkQ0JEUVRDQ0FTSXdEUVlKS29aSWh2Y05BUU V CQlFBRGdnRVBBRENDQVFvQ2dnRUJBTWJNNVhQbQorOVM3NVMwdE1xYmY1WUUveWMwbFNiWnhLc1B W bERSbm9nb2NzRjlwcGtDeHhMZXlqOUNZcEtsQldUclQzSlRXClBOdDBPS1JLekUwbGd2ZEtwVk1T T 083elNXMXhrWDVqdHF1bVg4T2toUGhQWWxHKytNWHMyemlTNHdibENKRU0KeENoQlZmdkxXb2tWZ m 5Ib05iOU5jZ2s5dmpvNFVGdDNNUnVOczhja1JacW5yRzBBRkZvRXQ3b1Q2MUVLbUVGQgpJazVsWV l lQlFWQ21lVnlKM2hsS1Y5VXU1bDBjVXl4K21NMGFCaGFrYUhQUU5BUVRYS0Z4MDFwOFZkdGVaT0U z Cmh6QldCT1VSdENtQUV2RjVPWWlpQWhGOEoyYTNpTGQ0OHNvS3FEaXJDbVRDdjJaZGxZVEJvU1Vl a DEwYVVBc2cKRXN4QnUyNExVVGk0UzhzQ0F3RUFBYU5qTUdFd0RnWURWUjBQQVFIL0JBUURBZ0dHT U E4R0ExVWRFd0VCL3dRRgpNQU1CQWY4d0hRWURWUjBPQkJZRUZMRSt3MmtEK0w5SEFkU1lKaG9JQX U 5alpDdkRNQjhHQTFVZEl3UVlNQmFBCkZMRSt3MmtEK0w5SEFkU1lKaG9JQXU5alpDdkRNQTBHQ1N x R1NJYjNEUUVCQlFVQUE0SUJBUUFjR2dhWDNOZWMKbnp5SVpnWUlWeUhiSVVmNEttZXF2eGd5ZGtB U VY4R0s4M3JaRVdXT05mcWUvRVcxbnRsTU1VdTRrZWhETEk2egplTTdiNDFONWNkYmxJWlFCMmxXS G 1pUms5b3Btek42Y044Mm9OTEZwbXlQSW5uZ2lLM0JENDFWSE1XRVo3MWpGCmhTOU9NUGFnTVJZan l PZmlaUll6eTc4YUc2QTkrTXBlaXpHTFlBaUpMUXdHWEZLM3hQa0ttTkVWWDU4U3ZudzIKWXppOVJ L Ui81Q1lyQ3NTWGFRM3BqT0xBRUZlNHlIWVNrVlh5U0duWXZDb0NXdzlFMUNBeDIvUzZjQ1pka0dD Z Qp2RXNYQ1MrMHl4NURhTWtISjhIU1hQZnFJYmxvRXB3OG5MK2UvSUJjbTJQTjdFZXFKU2Rub0Rme k FJSjlWTmVwCitPa3VFNk4zNkI5SwotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCi0tLS0tQkVHSU 4 gQ0VSVElGSUNBVEUtLS0tLQpNSUlFMkRDQ0JFR2dBd0lCQWdJRU4wclNRekFOQmdrcWhraUc5dzB C QVFVRkFEQ0J3ekVMTUFrR0ExVUVCaE1DVlZNeEZEQVNCZ05WCkJBb1RDMFZ1ZEhKMWMzUXVibVYw T VRzd09RWURWUVFMRXpKM2QzY3VaVzUwY25WemRDNXVaWFF2UTFCVElHbHVZMjl5Y0M0Z1lua2cKY 2 1WbUxpQW9iR2x0YVhSeklHeHBZV0l1S1RFbE1DTUdBMVVFQ3hNY0tHTXBJREU1T1RrZ1JXNTBjbl Z 6ZEM1dVpYUWdUR2x0YVhSbApaREU2TURnR0ExVUVBeE14Ulc1MGNuVnpkQzV1WlhRZ1UyVmpkWEp s SUZObGNuWmxjaUJEWlhKMGFXWnBZMkYwYVc5dUlFRjFkR2h2CmNtbDBlVEFlRncwNU9UQTFNalV4 T mpBNU5EQmFGdzB4T1RBMU1qVXhOak01TkRCYU1JSERNUXN3Q1FZRFZRUUdFd0pWVXpFVU1CSUcKQ T FVRUNoTUxSVzUwY25WemRDNXVaWFF4T3pBNUJnTlZCQXNUTW5kM2R5NWxiblJ5ZFhOMExtNWxkQz l EVUZNZ2FXNWpiM0p3TGlCaQplU0J5WldZdUlDaHNhVzFwZEhNZ2JHbGhZaTRwTVNVd0l3WURWUVF M RXh3b1l5a2dNVGs1T1NCRmJuUnlkWE4wTG01bGRDQk1hVzFwCmRHVmtNVG93T0FZRFZRUURFekZG Y m5SeWRYTjBMbTVsZENCVFpXTjFjbVVnVTJWeWRtVnlJRU5sY25ScFptbGpZWFJwYjI0Z1FYVjAKY U c5eWFYUjVNSUdkTUEwR0NTcUdTSWIzRFFFQkFRVUFBNEdMQURDQmh3S0JnUUROS0lNMFZCdUo4dy t 2TjVFeC82OHhZTW1vNkxJUQphTzJmNTVNMjhRcGt1MGYxQkJjL0kwZE54U2NaZ1NZTVZISU5pQzN a SDVvU243eXpjZE9BR1Q5SFpudU1OU2pTdVFyZkpOcWMxbEI1CmdYcGEwemYzd2tyWUtaSW1aTkhr b Ud3NkFJcjFOSnRsK08zakVQLzl1RWxZM0tEZWdqbHJnYkVXR1dHNVZMYm1Rd0lCQTZPQ0FkY3cKZ 2 dIVE1CRUdDV0NHU0FHRytFSUJBUVFFQXdJQUJ6Q0NBUmtHQTFVZEh3U0NBUkF3Z2dFTU1JSGVvSU h ib0lIWXBJSFZNSUhTTVFzdwpDUVlEVlFRR0V3SlZVekVVTUJJR0ExVUVDaE1MUlc1MGNuVnpkQzV 1 WlhReE96QTVCZ05WQkFzVE1uZDNkeTVsYm5SeWRYTjBMbTVsCmRDOURVRk1nYVc1amIzSndMaUJp Z VNCeVpXWXVJQ2hzYVcxcGRITWdiR2xoWWk0cE1TVXdJd1lEVlFRTEV4d29ZeWtnTVRrNU9TQkYKY m 5SeWRYTjBMbTVsZENCTWFXMXBkR1ZrTVRvd09BWURWUVFERXpGRmJuUnlkWE4wTG01bGRDQlRaV0 4 xY21VZ1UyVnlkbVZ5SUVObApjblJwWm1sallYUnBiMjRnUVhWMGFHOXlhWFI1TVEwd0N3WURWUVF E RXdSRFVrd3hNQ21nSjZBbGhpTm9kSFJ3T2k4dmQzZDNMbVZ1CmRISjFjM1F1Ym1WMEwwTlNUQzl1 W lhReExtTnliREFyQmdOVkhSQUVKREFpZ0E4eE9UazVNRFV5TlRFMk1EazBNRnFCRHpJd01Ua3cKT l RJMU1UWXdPVFF3V2pBTEJnTlZIUThFQkFNQ0FRWXdId1lEVlIwakJCZ3dGb0FVOEJkaUUxVTlzLz h LQUd2N1VJU1g4KzFpMEJvdwpIUVlEVlIwT0JCWUVGUEFYWWhOVlBiUC9DZ0JyKzFDRWwvUHRZdEF h TUF3R0ExVWRFd1FGTUFNQkFmOHdHUVlKS29aSWh2WjlCMEVBCkJBd3dDaHNFVmpRdU1BTUNCSkF3 R FFZSktvWklodmNOQVFFRkJRQURnWUVBa053d0F2cGtkTUtuQ3FWOElZMDBGNmo3Unc3L0pYeU4KR X dyNzVKaTE3NHo0eFJBTjk1Sys4Y1BWMVpWcUJMc3N6aVkyWmNneHh1ZnVQK05YZFlSNkVlOUdUeG o wMDVpN3FJY3l1bkwyUE9JOQpuOWNkMmNOZ1E0eFlEaUtXTDJLakxCKzZyUVh2cXpKNGg2QlVjeG0 x WEFYNVVqNXRMVVVMOXdxVDZ1MEcrYkk9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0KLS0tLS1C R UdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUdWVENDQlQyZ0F3SUJBZ0lRQ0ZINVdZRkJSY3E5NENUa U VzbkNEakFOQmdrcWhraUc5dzBCQVFVRkFEQnMKTVFzd0NRWURWUVFHRXdKVlV6RVZNQk1HQTFVRU N oTU1SR2xuYVVObGNuUWdTVzVqTVJrd0Z3WURWUVFMRXhCMwpkM2N1WkdsbmFXTmxjblF1WTI5dE1 T c3dLUVlEVlFRREV5SkVhV2RwUTJWeWRDQklhV2RvSUVGemMzVnlZVzVqClpTQkZWaUJTYjI5MElF T kJNQjRYRFRBM01EUXdNekF3TURBd01Gb1hEVEl5TURRd016QXdNREF3TUZvd1pqRUwKTUFrR0ExV U VCaE1DVlZNeEZUQVRCZ05WQkFvVERFUnBaMmxEWlhKMElFbHVZekVaTUJjR0ExVUVDeE1RZDNkMw p MbVJwWjJsalpYSjBMbU52YlRFbE1DTUdBMVVFQXhNY1JHbG5hVU5sY25RZ1NHbG5hQ0JCYzNOMWN t RnVZMlVnClEwRXRNekNDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFM O WhDaWtRSDE3K05EZFIKQ1BnZSt5THRZYjRMRFhCTVVHTW1kUlc1UVlpWHR2Q2dGYnNJWU9CQzZBV X BFSWMyaWlobHFPOHhCM1J0TnBjdgpLRVptQk1jcWVTWjZtZFdPdzIxUG9GNnR2RDJSd2xsN1hqWn N 3RlBQQUFneVBoQmtXQkFUYWNjTTdweENVUUQ1CkJVVHVKTTU2SCsyTUViMFNxUE1WOUJ4Nk1Xa0J H NmZtWGNDYWJINEpudWRTUkVvUU9pUGttN1lEcjZpY3RGdWYKMUV1dGtvek90UkVxcWpjWWpiVEN1 T mhjQm96NC95TzlOVjdVZkQ1K2d3NlJsZ1dZdzdJZjQ4aGw2Nmw3WGFBcwp6UHc4MlczdHpQcExRN H pKMUxpbFlSeXlRTFlvRXQrNStGLyswN0xKN3oyMEhrdDhIRXlaTnA0OTYreW5hRjRkCjMyZHVYdn N DQXdFQUFhT0NBdmN3Z2dMek1BNEdBMVVkRHdFQi93UUVBd0lCaGpDQ0FjWUdBMVVkSUFTQ0FiMHc K Z2dHNU1JSUJ0UVlMWUlaSUFZYjliQUVEQUFJd2dnR2tNRG9HQ0NzR0FRVUZCd0lCRmk1b2RIUndP a Th2ZDNkMwpMbVJwWjJsalpYSjBMbU52YlM5emMyd3RZM0J6TFhKbGNHOXphWFJ2Y25rdWFIUnRNS U lCWkFZSUt3WUJCUVVICkFnSXdnZ0ZXSG9JQlVnQkJBRzRBZVFBZ0FIVUFjd0JsQUNBQWJ3Qm1BQ0 F BZEFCb0FHa0Fjd0FnQUVNQVpRQnkKQUhRQWFRQm1BR2tBWXdCaEFIUUFaUUFnQUdNQWJ3QnVBSE1 B ZEFCcEFIUUFkUUIwQUdVQWN3QWdBR0VBWXdCagpBR1VBY0FCMEFHRUFiZ0JqQUdVQUlBQnZBR1lB S UFCMEFHZ0FaUUFnQUVRQWFRQm5BR2tBUXdCbEFISUFkQUFnCkFFTUFVQUF2QUVNQVVBQlRBQ0FBW V FCdUFHUUFJQUIwQUdnQVpRQWdBRklBWlFCc0FIa0FhUUJ1QUdjQUlBQlEKQUdFQWNnQjBBSGtBSU F CQkFHY0FjZ0JsQUdVQWJRQmxBRzRBZEFBZ0FIY0FhQUJwQUdNQWFBQWdBR3dBYVFCdApBR2tBZEF B Z0FHd0FhUUJoQUdJQWFRQnNBR2tBZEFCNUFDQUFZUUJ1QUdRQUlBQmhBSElBWlFBZ0FHa0FiZ0Jq C kFHOEFjZ0J3QUc4QWNnQmhBSFFBWlFCa0FDQUFhQUJsQUhJQVpRQnBBRzRBSUFCaUFIa0FJQUJ5Q U dVQVpnQmwKQUhJQVpRQnVBR01BWlFBdU1BOEdBMVVkRXdFQi93UUZNQU1CQWY4d05BWUlLd1lCQl F VSEFRRUVLREFtTUNRRwpDQ3NHQVFVRkJ6QUJoaGhvZEhSd09pOHZiMk56Y0M1a2FXZHBZMlZ5ZEM 1 amIyMHdnWThHQTFVZEh3U0JoekNCCmhEQkFvRDZnUElZNmFIUjBjRG92TDJOeWJETXVaR2xuYVdO b GNuUXVZMjl0TDBScFoybERaWEowU0dsbmFFRnoKYzNWeVlXNWpaVVZXVW05dmRFTkJMbU55YkRCQ W 9ENmdQSVk2YUhSMGNEb3ZMMk55YkRRdVpHbG5hV05sY25RdQpZMjl0TDBScFoybERaWEowU0dsbm F FRnpjM1Z5WVc1alpVVldVbTl2ZEVOQkxtTnliREFmQmdOVkhTTUVHREFXCmdCU3hQc05wQS9pL1J 3 SFVtQ1lhQ0FMdlkyUXJ3ekFkQmdOVkhRNEVGZ1FVVU9wemlkc3AreENQbnVVQklOVGUKZVpsSWcv Y 3dEUVlKS29aSWh2Y05BUUVGQlFBRGdnRUJBRjFQaFBHb2lOT2pzcnljYmVVcFNYZmg1OWJjcWRnM Q pyc2x4M09YYjNKMGtJWkNtejdjQkhKdlVWNWVSMTNVV3BSTFh1VDB1aVQwNWFZcldOVGY1OFNIRV c wQ3RXYWt2Clh6b0FLVU1uY1FQa3ZUQXlWYWIraEE0TG16Z1pMRU44ckVPL2RUSGxJeHhGVmJkcEN K RzF6OWZWc1Y3dW41VGsKMW5xNUdNTzQxbEpqSEJDNml5OXRYY3dGT1BSV0JXM3ZudXpvWVRZTUZF d UZGRm9NZzA4aVhGbkxqSXB4MnZyRgpFSVJZendmdTQ1REM5ZmtweDFvamNmbFp0R1FyaUxDbk5zZ W FJR0hyK2s2MXJtc2I1T1BzNHRrOFFVbW9JS1JVCjlaS051OEJWSUFTbTJMQVhGc3pqME1pMFBlWF p oTWJUOW01dGVNbDVRK2g2Ti85Y05VbS9vY1U9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0KLS0 t LS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUVRakNDQTZ1Z0F3SUJBZ0lFUW9kQXBUQU5CZ2tx a GtpRzl3MEJBUVVGQURDQnd6RUxNQWtHQTFVRUJoTUMKVlZNeEZEQVNCZ05WQkFvVEMwVnVkSEoxY z NRdWJtVjBNVHN3T1FZRFZRUUxFekozZDNjdVpXNTBjblZ6ZEM1dQpaWFF2UTFCVElHbHVZMjl5Y0 M 0Z1lua2djbVZtTGlBb2JHbHRhWFJ6SUd4cFlXSXVLVEVsTUNNR0ExVUVDeE1jCktHTXBJREU1T1R r Z1JXNTBjblZ6ZEM1dVpYUWdUR2x0YVhSbFpERTZNRGdHQTFVRUF4TXhSVzUwY25WemRDNXUKWlhR Z 1UyVmpkWEpsSUZObGNuWmxjaUJEWlhKMGFXWnBZMkYwYVc5dUlFRjFkR2h2Y21sMGVUQWVGdzB3T m pFdwpNREV3TlRBd01EQmFGdzB4TkRBM01qWXhPREUxTVRWYU1Hd3hDekFKQmdOVkJBWVRBbFZUTV J Vd0V3WURWUVFLCkV3eEVhV2RwUTJWeWRDQkpibU14R1RBWEJnTlZCQXNURUhkM2R5NWthV2RwWTJ W eWRDNWpiMjB4S3pBcEJnTlYKQkFNVElrUnBaMmxEWlhKMElFaHBaMmdnUVhOemRYSmhibU5sSUVW V 0lGSnZiM1FnUTBFd2dnRWlNQTBHQ1NxRwpTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lCQVFER 3 pPVno1dnZVdStVdExUS20zK1dCUDhuTkpVbTJjU3JECjFaUTBaNklLSExCZmFhWkFzY1Mzc28vUW 1 LU3BRVms2MDl5VTFqemJkRGlrU3N4TkpZTDNTcVZURWpqdTgwbHQKY1pGK1k3YXJwbC9EcElUNFQ y SlJ2dmpGN05zNGt1TUc1UWlSRE1Rb1FWWDd5MXFKRlg1eDZEVy9UWElKUGI0NgpPRkJiZHpFYmpi U EhKRVdhcDZ4dEFCUmFCTGU2RSt0UkNwaEJRU0pPWldHSGdVRlFwbmxjaWQ0WlNsZlZMdVpkCkhGT X NmcGpOR2dZV3BHaHowRFFFRTF5aGNkTmFmRlhiWG1UaE40Y3dWZ1RsRWJRcGdCTHhlVG1Jb2dJUm Z DZG0KdDRpM2VQTEtDcWc0cXdwa3dyOW1YWldFd2FFbEhvZGRHbEFMSUJMTVFidHVDMUU0dUV2TEF n TUJBQUdqZ2dFVApNSUlCRHpBU0JnTlZIUk1CQWY4RUNEQUdBUUgvQWdFQk1DY0dBMVVkSlFRZ01C N EdDQ3NHQVFVRkJ3TUJCZ2dyCkJnRUZCUWNEQWdZSUt3WUJCUVVIQXdRd013WUlLd1lCQlFVSEFRR U VKekFsTUNNR0NDc0dBUVVGQnpBQmhoZG8KZEhSd09pOHZiMk56Y0M1bGJuUnlkWE4wTG01bGREQX p CZ05WSFI4RUxEQXFNQ2lnSnFBa2hpSm9kSFJ3T2k4dgpZM0pzTG1WdWRISjFjM1F1Ym1WMEwzTmx j blpsY2pFdVkzSnNNQjBHQTFVZERnUVdCQlN4UHNOcEEvaS9Sd0hVCm1DWWFDQUx2WTJRcnd6QUxC Z 05WSFE4RUJBTUNBUVl3SHdZRFZSMGpCQmd3Rm9BVThCZGlFMVU5cy84S0FHdjcKVUlTWDgrMWkwQ m 93R1FZSktvWklodlo5QjBFQUJBd3dDaHNFVmpjdU1RTUNBSUV3RFFZSktvWklodmNOQVFFRgpCUU F EZ1lFQVNBNHJieUJpVENpVG95UTlXS3NoejRENG1wZVFhaUx0V254SE5wbm5lWVIxcXlTUGtnclZ Z UVN1CncycGNzc3paNUVTSGI5dVBPR0wzUkRhZHVyeHVCOFRVamVnZjBRdGdvN1djem1PKzdXZmMr T HJlYnNrbHkxdTEKblhad0M5OUNjdmhQUVJGa3BkTHEvTld2RWZRVk9HZWNJS2hMZDFxUk1rSXk1N F d6M3pZPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0t reqMod: entryCSN:= 20120816203211.268678Z#000000#002#000000 reqMod: modifiersName:= uid=zimbra,cn=admins,cn=zimbra reqMod: modifyTimestamp:= 20120816203211Z reqEntryUUID: 74dae3e4-7c2b-1031-8ea4-53683769021c entryUUID: 337b4d42-7c2d-1031-8ad2-31a7d38e08d4 creatorsName: cn=config createTimestamp: 20120816203211Z entryCSN: 20120816203211.268678Z#000000#002#000000 modifiersName: cn=config modifyTimestamp: 20120816203211Z --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#7354) segfault with delta-syncrepl MMR
by quanah＠zimbra.com 16 Aug '12

16 Aug '12

--On Thursday, August 16, 2012 11:09 PM +0000 quanah(a)zimbra.com wrote: > --On Wednesday, August 15, 2012 9:36 PM +0000 quanah(a)zimbra.com wrote: Crash occurs with this op: Aug 16 16:50:27 zqa-129 slapd[30991]: slap_queue_csn: queing 0x7fd7d0002b29 20120816203158.675452Z#000000#001#000000 In the zqa-128 accesslog, I find: dn: reqStart=20120816203158.000011Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20120816203158.000011Z reqEnd: 20120816203158.000012Z reqType: modify reqSession: 1003 reqAuthzID: uid=zimbra,cn=admins,cn=zimbra reqDN: cn=zqa-129.eng.vmware.com,cn=servers,cn=zimbra reqResult: 0 reqMod:: emltYnJhU1NMUHJpdmF0ZUtleTo9IC0tLS0tQkVHSU4gUlNBIFBSSVZBVEUgS0VZLS0tL S0KTUlJRXBBSUJBQUtDQVFFQXBmcE4va0NJSW5nM003RDMyNWMxN3VtMktQWmdBNTNVNHB0UnVqY U pCK2tKWHVlaApHRll2OUVlK1JlNlhzN3YrWVBIV2xvNmdXemFHZURLaUgreXNkeUhYVWpRdDhzeU g 4WXJ5Z0w5eGorQlhBWHRnCjVKKy90Qk9HTmJ4Vi8yVncrMS9xTll0bkFLbktsUDh5OXEvand3TnJ n U08xZXpkUFFtSlBScjEzN1h3Z01hMFMKSzN1WFNHM1BJdTlmWnBxSHdzYWVsU0E1ZGp5TFlRVHhr Z GNkdkVic3NjU3pvOC9OYjNFaklmaEtzcU9NOEczYwpPMGszeUYzVXZvMU9OUFA2QnFwMEI3UmJWT F lDaGh5RlJQK1VvdC9oRzVKcWpLOE9kMFpBT3Q3eDhqUm9zQTJRCnA2bmFCcjNmdFB2S3lwL1RDZ0 1 pZ1VjNHFIZzFRNnZoNXFVSnJRSURBUUFCQW9JQkFRQ2wzSHNpRDdTNjFXMDgKajZVd1lHdjZBcjB S TkJ1QW9iR0NmZm51M3Q2UzlCSjBMMzR4aHJkSElvYUc5Y1hOUzVrSm9jSnlFN2MxVDBpVApSdTN5 Z ngxZHM0aXIwZzcwcWVWVHdDbFQ5WHZ6Ymhra0Z2b2RuWElCN3R6WVNBdWNPKy9xazgvRmtEZnZWc j FsCnBaeDFIaEc1NkduKzFBTmdUVVk4TFdmUlpqYzVMb3d4QnVEb0tnczdaZ00rZHo5aytlbWNXTz N 1bDJYUFpPSm0KZlFTWWFlM0JaQVlHWTBwZnVXM0xFdFFDdDdkbkZjS2xNSU5FZWNudXRUaGpyb0R h cjZkQ2ZRN1hkUE1mUVRXQQorQWt3YzZoYXk0WnpaUWdwTStXeVdvcE9iT2luc09ObG9HZkhTL3gz N XN6Q1Exc3FCNGlwaEtoc0hQTnZsTUg4Ck5XVXE2L25oQW9HQkFOQTh4V09OTWdYMmZJN0dNZk8xY X lCdUdSTlQ3Ym4ydUc4by9pdkZmM08zdGp2RlRFUkUKUzExR2kwN3l5SDhnR3BRVTdHR0VXY1ZBM2 g weG1mNWV6cndNMVduOFFQOFRWYkMwTitvM3RQWDNHWWs0cm5UcQpUOVdHV2VDbUhaMlRQYlprVHY 1 N2FwU3RRNkpQU0ZZSVFEM2xHd3YvOFZwNVZXeWh5cXpiek42bEFvR0JBTXdNCkpMSm82VHY5Z0Nu W FRYa25VOTBuSVA5RkVkbGJoUmFZcWxkM2hEcXVyTkJ6bWQ5OU5kclVKVTlDUm14dUFtTjQKUytIV 0 V0MVl4MW9Mbks4U3NtRFcwWkVhclQ3YUFORkdIbjhSNHBTVGpEUnJ2SWdsNUVodVpURW9vUnVnWT Z kYwpUcTRaZERQamhUeXJncHkvQkV0bjVJcnhDQ0Q0Vi9WcHlQZG5zVmhwQW9HQWZRQ09DVldmK3I 1 ZFJTT3FwcjUzCjRVN1dGS2trSXFiOVRoVlFocHdYQnpMMzNPZHlBZVR4VEx2bE1tNUJkemFoWGRV M WxOQnJSeUxLY3NIc3pDckQKZFZWSzQwVi9DdC9qWjZDM2xBeit2MHdtOHgyb2RCeVg4ZmlsaVZxT 2 1xSGh3TlIwS3dXUkZGRHlNY1BnQzIwRwppMkUxbkQxMjk3V3dWdmJFZ0lHdGVOVUNnWUVBbkV5Yy s 1RERQL0d4NzlyOWZGVjB0dzNYQjlMSGxtQzFkSmFpCnZQZE84WWlGMWZNSEpodUtXa0p4QmVKMWd X OVBJeFN0dzZNd3RoN2dMWWlCajlYWmo3WmR0ekhoRFNqK3dVOWQKNHVZM1Vxb25GcXlFTVNJZFdL S S9uMFZKQzVselhHcW4xbEtuSVd3aHpsUnVhMVVpbkFSTUcyWUFYUWorajMxbAp0S1hZUWlrQ2dZQ n h2NDM0WlA1b1JYM1Q3cGYyODRDTCtEcnFvK3o2Q1M0R3VRV3lnTm5ybkhWcWF5WWNzdWpWCjk3VH R QVmM3TXBYZDdOTkd3UTYrMVBvY1p0MWtYUS9KZExhc1R2enlwcmJuUmgrVVlrYzRZZXk1SFZaODJ Z NG8KWUpjWUtJWjlUOW1UVktrU2xnTitUZHp4cDFONFRSV3kxM2hmaXlUN1VncXFUSEpJYUpIaTJB P T0KLS0tLS1FTkQgUlNBIFBSSVZBVEUgS0VZLS0tLS0= reqMod: entryCSN:= 20120816203158.675452Z#000000#001#000000 reqMod: modifiersName:= uid=zimbra,cn=admins,cn=zimbra reqMod: modifyTimestamp:= 20120816203158Z reqEntryUUID: 74dae3e4-7c2b-1031-8ea4-53683769021c entryUUID: 2bf65684-7c2d-1031-8ad1-31a7d38e08d4 creatorsName: cn=config createTimestamp: 20120816203158Z entryCSN: 20120816203158.675452Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20120816203158Z --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#7354) segfault with delta-syncrepl MMR
by quanah＠zimbra.com 16 Aug '12

16 Aug '12

--On Wednesday, August 15, 2012 9:36 PM +0000 quanah(a)zimbra.com wrote: > --On Wednesday, August 15, 2012 7:46 PM +0000 quanah(a)OpenLDAP.org wrote: Full backtrace: #0 0x00000000004c02b8 in syncrepl_op_modify (op=0x7fd7d8b43460, rs=0x7fd7d8b42e40) at syncrepl.c:2133 sc = 0x10793f8 mx = 0x1079418 ml = 0x40 on = 0x89f2d0 oex = 0x7fd7d8b42ed0 si = 0x89ec20 e = 0x1077ba0 rc = 0 match = -256 mod = 0x12a4c70 newlist = 0x1077b40 #1 0x00000000004d48f4 in overlay_op_walk (op=0x7fd7d8b43460, rs=0x7fd7d8b42e40, which=op_modify, oi=0x89f0f0, on=0x89f2d0) at backover.c:661 func = 0x89f328 rc = 32768 #2 0x00000000004d4bca in over_op_func (op=0x7fd7d8b43460, rs=0x7fd7d8b42e40, which=op_modify) at backover.c:723 oi = 0x89f0f0 on = 0x89f2d0 be = 0x8a2da0 db = {bd_info = 0x89f2d0, bd_self = 0x8a2da0, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", '\000' <repeats 14 times>, "\001", be_flags = 563464, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x89c9c0, be_nsuffix = 0x8a8ff0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val = 0x8c50c0 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x8c50a0 "cn=config"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = -1, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x8a90a0, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x862b80, be_pcl_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}, be_syncinfo = 0x89ec20, be_pb = 0x0, be_cf_ocs = 0x7ffff15e4ac0, be_private = 0x7ffff7e30010, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7fd7d8b42eb0, sc_response = 0x4d36c4 <over_back_response>, sc_cleanup = 0, sc_private = 0x89f0f0} sc = 0x35f638a0d3 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #3 0x00000000004d4d35 in over_op_modify (op=0x7fd7d8b43460, rs=0x7fd7d8b42e40) at backover.c:762 No locals. #4 0x00000000004c1353 in syncrepl_message_to_op (si=0x89ec20, op=0x7fd7d8b43460, msg=0x1288750) at syncrepl.c:2317 oes = {oe = {oe_next = {sle_next = 0x0}, oe_key = 0x4c03ac}, oe_si = 0x89ec20} ber = 0x129a900 modlist = 0x12a4bb0 ls = 0x75d400 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} cb = {sc_next = 0x0, sc_response = 0x4c890b <null_callback>, sc_cleanup = 0, sc_private = 0x0} text = 0x0 txtbuf = "\000G\264\330\327\177\000\000?8\366\377\177\000\000\200\060\264\330\327\177", '\000' <repeats 18 times>, "\001", '\000' <repeats 23 times>"\200, \060\264\330\327\177\000\000\000\000\200\000\000\000\000\000\300I\264\330\327\177\000\000\242\032\071\366\377\177", '\000' <repeats 18 times>"\300, \060\264\330\327\177\000\000\000\000\200\000\000\000\000\000\300I\264\330\327\177\000\000z5\227\367\377\177\000\000p\262|", '\000' <repeats 13 times>"\300, \355)\001\000\000\000\000\200\351)\001\000\000\000\000\340\060\264\330\327\177\000\000\200\351)\001\000\000\000\000\340\060\264\330\327\177\000\000\314\065\227\367\377\177\000\000\300\355)\001\000\000\000\000\200\351)\001\000\000\000\000 1\264\330\327\177\000\000mrM\000\000\000\000\000 1\264\330\327\177\000\000\300\355)\001\000\000\000" textlen = 256 bdn = {bv_len = 46, bv_val = 0x129a09b "cn=zqa-129.eng.vmware.com,cn=servers,cn=zimbra"} dn = {bv_len = 46, bv_val = 0x1077d68 "x\204\a\001"} ndn = {bv_len = 46, bv_val = 0x1077df8 " \321", <incomplete sequence \366>} bv = {bv_len = 0, bv_val = 0x0} bv2 = {bv_len = 0, bv_val = 0x0} bvals = 0x1299b40 rdn = {bv_len = 0, bv_val = 0x0} sup = {bv_len = 0, bv_val = 0x0} prdn = {bv_len = 0, bv_val = 0x0} nrdn = {bv_len = 0, bv_val = 0x0} psup = {bv_len = 0, bv_val = 0x0} nsup = {bv_len = 0, bv_val = 0x0} rc = 0 deleteOldRdn = 0 freeReqDn = 1 do_graduate = 1 #5 0x00000000004bc45f in do_syncrep2 (op=0x7fd7d8b43460, si=0x89ec20) at syncrepl.c:986 match = 0 cookie = {bv_len = 60, bv_val = 0x1299d49 "rid=100,sid=001,csn=20120816203158.675452Z#000000#001#000000"} rctrls = 0x1299280 rctrlp = 0x12a4970 syncUUIDs = 0x0 bdn = {bv_len = 44, bv_val = 0x129a049 "reqStart=20120816203158.000011Z,cn=accesslog"} syncUUID = {{bv_len = 16, bv_val = 0x1299d37 "+\366V\204|-\020\061\212\321\061\247?\b", <incomplete sequence \324>}, {bv_len = 16171360, bv_val = 0x7ffff7b8e345 "\311\303UH\211\345\350X\275\377\377\311\303UH\211\345H\203\354\020H\211}\370H\213E", <incomplete sequence \370\276>}} si_tag = 0 entry = 0x7fd7d8b43240 punlock = 0 syncstate = 1 retdata = 0x100000 retoid = 0x38 <Address 0x38 out of bounds> len = 60 berbuf = { buffer = "\002\000\001", '\000' <repeats 29 times>, "0\235)\001\000\000\000\000\205\235)\001\000\000\000\000\205\235)\001", '\000' <repeats 28 times>, "`3\264\330\327\177\000\000E\343\270\367\377\177\000\000`3\264\330\327\177\000\000\300\362u\000\000\000\000\000`3\264\330\327\177\000\000P\224E\000\000\000\000\000x4\264\330\327\177\000\000E\343\270\367\377\177\000\000\260\063\264\330\327\177\000\000?'\001\000\000\000\000\360\063\264\330\327\177\000\000\\2\273\367\377\177\000\000`4\264\330\327\177\000\000T4\264\330\327\177\000\000\000\000\000\000\001\000\000\000`\301\366\000\000\000\000\000\000\000\000\000 \000\000\000`4\264\330\327\177\000\000\360\063\264\330\327\177\000\000\261\376C\000\000\000\000\000\360\063\264\330\327\177\000\000`\255'\001\000\000\000", ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <Address 0x10002 out of bounds>} ber = 0x7fd7d8b432d0 msg = 0x1288750 syncCookie = {ctxcsn = 0x129edc0, sids = 0x12a2c40, numcsns = 1, rid = 100, octet_str = {bv_len = 60, bv_val = 0x12a55b0 "rid=100,sid=001,csn=20120816203158.675452Z#000000#001#000000"}, sid = 1, sc_next = {stqe_next = 0x0}} syncCookie_req = {ctxcsn = 0x12a4e70, sids = 0x1288a40, numcsns = 2, rid = 100, octet_str = {bv_len = 101, bv_val = 0x12886e0 "rid=100,sid=002,csn=20120816202735.336631Z#000000#000#000000;20120816202950.988904Z#000000#001#000000"}, sid = 2, sc_next = {stqe_next = 0x0}} rc = 0 err = 0 modlist = 0x0 m = 0 tout_p = 0x0 tout = {tv_sec = 0, tv_usec = 0} refreshDeletes = 0 empty = "empty" __PRETTY_FUNCTION__ = "do_syncrep2" #6 0x00000000004be6ba in do_syncrepl (ctx=0x7fd7d8b43b70, arg=0x89f510) at syncrepl.c:1523 rtask = 0x89f510 si = 0x89ec20 conn = {c_struct_state = SLAP_C_UNINITIALIZED, c_conn_state = SLAP_C_INVALID, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_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}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 18446744073709551615, c_peer_domain = {bv_len = 0, bv_val = 0x4f9ef0 ""}, c_peer_name = {bv_len = 0, bv_val = 0x4f9ef0 ""}, c_listener = 0x501e20, c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = {bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_write1_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}, c_write1_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_write2_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}, c_write2_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_writers = 0, c_writing = 0 '\000', c_sasl_bind_in_progress = 0 '\000', c_writewaiter = 0 '\000', c_is_tls = 0 '\000', c_needs_tls_accept = 0 '\000', c_sasl_layers = 0 '\000', c_sasl_done = 0 '\000', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0, c_clientarg = 0x0, c_send_ldap_result = 0x454b95 <slap_send_ldap_result>, c_send_search_entry = 0x45589d <slap_send_search_entry>, c_send_search_reference = 0x457b94 <slap_send_search_reference>, c_send_ldap_extended = 0x4553fc <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x45567a <slap_send_ldap_intermediate>} opbuf = {ob_op = {o_hdr = 0x7fd7d8b435d0, o_tag = 102, o_time = 1345158368, o_tincr = 85, o_bd = 0x7fd7d8b42c30, o_req_dn = {bv_len = 46, bv_val = 0x12a4bf0 "cn=zqa-129.eng.vmware.com,cn=servers,cn=zimbra"}, o_req_ndn = {bv_len = 46, bv_val = 0x12a4c30 "cn=zqa-129.eng.vmware.com,cn=servers,cn=zimbra"}, o_request = {oq_add = {rs_modlist = 0x12a4bb0, rs_e = 0x1}, oq_bind = {rb_method = 19549104, rb_cred = {bv_len = 1, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x12a4bb0}, oq_modify = {rs_mods = {rs_modlist = 0x12a4bb0, rs_no_opattrs = 1 '\001'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x12a4bb0, rs_no_opattrs = 1 '\001'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = { bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = {rs_scope = 19549104, rs_deref = 0, rs_slimit = 1, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = {rs_msgid = 19549104}, oq_cancel = {rs_msgid = 19549104}, oq_extended = {rs_reqoid = {bv_len = 19549104, bv_val = 0x1 <Address 0x1 out of bounds>}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = { bv_len = 19549104, bv_val = 0x1 <Address 0x1 out of bounds>}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 1 '\001', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 14 times>, "\002", '\000' <repeats 16 times>, o_controls = 0x7fd7d8b43718, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 9, bv_val = 0x8c50c0 "cn=config"}, sai_ndn = {bv_len = 9, bv_val = 0x8c50a0 "cn=config"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x10793f8, o_ctrls = 0x0, o_csn = {bv_len = 40, bv_val = 0x1077b08 "20120816203158.675452Z#000000#001#000000"}, o_private = 0x0, o_extra = {slh_first = 0x7fd7d8b42ed0}, o_next = {stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 100, oh_conn = 0x7fd7d8b43820, oh_msgid = 0, oh_protocol = 0, oh_tid = 140565030389504, oh_threadctx = 0x7fd7d8b43b70, oh_tmpmemctx = 0xf6c0e0, oh_tmpmfuncs = 0x75d360, oh_counters = 0x760820, oh_log_prefix = "conn=-1 op=0", '\000' <repeats 243 times>}, ob_controls = {0x0 <repeats 17 times>, 0x7fd7d8b43190, 0x0 <repeats 14 times>}} op = 0x7fd7d8b43460 rc = 0 dostop = 0 s = 15 i = 1 defer = 1 fail = 0 freeinfo = 0 be = 0x8a2da0 #7 0x000000000043dfad in connection_read_thread (ctx=0x7fd7d8b43b70, argv=0xf) at connection.c:1288 rc = 0 cri = {op = 0x0, func = 0x4be0b7 <do_syncrepl>, arg = 0x89f510, ctx = 0x7fd7d8b43b70, nullop = 0} s = 15 #8 0x00007ffff7b8ccc9 in ldap_int_thread_pool_wrapper (xpool=0x7d4720) at tpool.c:688 pool = 0x7d4720 task = 0xf6c260 work_list = 0x7d47b8 ctx = {ltu_id = 140565030389504, ltu_key = {{ltk_key = 0x4b3757, ltk_data = 0xf6c0e0, ltk_free = 0x4b357c <slap_sl_mem_destroy>}, {ltk_key = 0x7fffda549010, ltk_data = 0x1179400, ltk_free = 0x7ffff13c864d <mdb_reader_free>}, {ltk_key = 0x7febda348010, ltk_data = 0x128a910, ltk_free = 0x7ffff13c864d <mdb_reader_free>}, {ltk_key = 0x7ffff13be478, ltk_data = 0x7fd7d4935010, ltk_free = 0x7ffff13be455 <search_stack_free>}, {ltk_key = 0x7ffff13bbe5d, ltk_data = 0x7fd7d5936010, ltk_free = 0x7ffff13bbe15 <scope_chunk_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>, {ltk_key = 0x0, ltk_data = 0x7ffff6696ca9, ltk_free = 0}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}}} kctx = 0x0 i = 32 keyslot = 649 hash = 423411337 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #9 0x00007ffff66959ca in start_thread (arg=<value optimized out>) at pthread_create.c:300 __res = <value optimized out> pd = 0x7fd7d8b44700 unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140565030389504, 7959847170449877608, 8388608, 140565030390208, 4, 140565030389504, -7937383527311463832, -7959863823191365016}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <value optimized out> robust = <value optimized out> freesize = <value optimized out> __PRETTY_FUNCTION__ = "start_thread" #10 0x00007ffff63f2cdd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 No locals. #11 0x0000000000000000 in ?? () (gdb) print *newlist $2 = {sml_mod = {sm_desc = 0xf769a0, sm_values = 0x0, sm_nvalues = 0x0, sm_numvals = 0, sm_op = 4097, sm_flags = 0, sm_type = {bv_len = 56, bv_val = 0x312d61717a3d6e63 <Address 0x312d61717a3d6e63 out of bounds>}}, sml_next = 0x40} (gdb) print *newlist->sml_mod.sm_desc $3 = {ad_next = 0x0, ad_type = 0xabc2f0, ad_cname = {bv_len = 19, bv_val = 0xabc1e0 "zimbraSSLPrivateKey"}, ad_tags = {bv_len = 0, bv_val = 0x0}, ad_flags = 0, ad_index = 1015} --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#7355) slapd reproducible segfaults deleting memberof from cn=config
by hyc＠symas.com 16 Aug '12

16 Aug '12

daniel(a)pluta.biz wrote: > Full_Name: Daniel Pluta > Version: HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.167.95.124) > > > Steps to reproduce: > > 0.) slapd version: HEAD (git master pulled today) cn=config does not support deletes. You should not be mucking with the (still incomplete) SLAP_CONFIG_DELETE code unless you're an actual C programmer working on completing the code. Closing this ITS, it's pointless to even mention this stuff until ITS #7254, #7256, #7257, and #7212 are addressed, and none of them are targeted for OpenLDAP 2.4. -- -- 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#7355) slapd reproducible segfaults deleting memberof from cn=config
by daniel＠pluta.biz 16 Aug '12

16 Aug '12

Full_Name: Daniel Pluta Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.167.95.124) Steps to reproduce: 0.) slapd version: HEAD (git master pulled today) 1.) slapd.conf: include /opt/openldap-acl/etc/openldap/schema/core.schema pidfile /opt/openldap-acl/var/run/slapd.pid argsfile /opt/openldap-acl/var/run/slapd.args modulepath /opt/openldap-acl/libexec/openldap moduleload memberof.la access to * by self write by users read by anonymous auth database config rootdn "cn=Manager,cn=config" rootpw secret database mdb suffix "o=test" rootdn "cn=Manager,o=test" rootpw secret directory /opt/openldap-acl/var/openldap-data/test index objectClass eq overlay memberof memberof-group-oc groupOfNames memberof-member-ad member memberof-memberof-ad memberOf memberof-dangling ignore memberof-refint FALSE 2.) conversion to slapd.d: /opt/openldap-acl/sbin/slaptest -f slapd.conf.acl -F slapd.d 3.) slapd start: slapd -F slapd.d -u openldap -g openldap -l local4 -d 1 \ -h "ldap://0.0.0.0:1389/ ldapi://%2Fopt%2Fopenldap%2Fvar%2Frun%2Fldapi_acl/" 4.) delete_memberof.ldif: dn: olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config changetype: delete 5.) ldapmodify: cat delete_memberof.ldif | ldapmodify -x -H "ldap://localhost:1389/" -D "cn=Manager,cn=config" -w secret Result: 502c9eeb slap_listener_activate(7): 502c9eeb >>> slap_listener(ldap://0.0.0.0:1389/) 502c9eeb connection_get(11): got connid=1000 502c9eeb connection_read(11): checking for input on id=1000 ber_get_next ber_get_next: tag 0x30 len 38 contents: 502c9eeb op tag 0x60, time 1345101547 ber_get_next 502c9eeb conn=1000 op=0 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: 502c9eeb >>> dnPrettyNormal: <cn=Manager,cn=config> 502c9eeb <<< dnPrettyNormal: <cn=Manager,cn=config>, <cn=manager,cn=config> 502c9eeb do_bind: version=3 dn="cn=Manager,cn=config" method=128 502c9eeb do_bind: v3 bind: "cn=Manager,cn=config" to "cn=Manager,cn=config" 502c9eeb send_ldap_result: conn=1000 op=0 p=3 502c9eeb send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 11 502c9eeb connection_get(11): got connid=1000 502c9eeb connection_read(11): checking for input on id=1000 ber_get_next ber_get_next: tag 0x30 len 56 contents: 502c9eeb op tag 0x4a, time 1345101547 ber_get_next 502c9eeb conn=1000 op=1 do_delete ber_scanf fmt (m) ber: 502c9eeb >>> dnPrettyNormal: <olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config> 502c9eeb <<< dnPrettyNormal: <olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config>, <olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config> Segmentation fault

1 0

Re: (ITS#7172) SEGFAULT in openldap-2.4.28 & 2.4.29
by hyc＠symas.com 15 Aug '12

15 Aug '12

A fix for this is now in git master, please test. Thanks. david.coutadeur(a)linagora.com wrote: > Hi, > > I had some difficulties to reproduce it, but I have finally succeeded : > > [Switching to Thread 0x431e4940 (LWP 11061)] > 0x000000000054211c in sp_avl_cmp (c1=<value optimized out>, > c2=0xbfb5a60) at syncprov.c:378 > 378 rc = m1->mt_op->o_req_ndn.bv_len - > m2->mt_op->o_req_ndn.bv_len; > > > Thank you for the help, > > David Coutadeur -- -- 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#7354) segfault with delta-syncrepl MMR
by quanah＠zimbra.com 15 Aug '12

15 Aug '12

--On Wednesday, August 15, 2012 7:46 PM +0000 quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.32 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.196.25.250) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fd7d8b44700 (LWP 28572)] 0x00000000004c02b8 in syncrepl_op_modify (op=0x7fd7d8b43460, rs=0x7fd7d8b42e40) at syncrepl.c:2133 2133 if ( ml->sml_flags == SLAP_MOD_INTERNAL ) { (gdb) print *ml Cannot access memory at address 0x40 (gdb) print newlist $1 = (Modifications *) 0x13a77d0 (gdb) print newlist->sml_next $2 = (Modifications *) 0x40 (gdb) print *newlist $3 = {sml_mod = {sm_desc = 0xf78a50, sm_values = 0x0, sm_nvalues = 0x0, sm_numvals = 0, sm_op = 4097, sm_flags = 0, sm_type = {bv_len = 56, bv_val = 0x312d61717a3d6e63 <Address 0x312d61717a3d6e63 out of bounds>}}, sml_next = 0x40} --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

(ITS#7354) segfault with delta-syncrepl MMR
by quanah＠OpenLDAP.org 15 Aug '12

15 Aug '12

Full_Name: Quanah Gibson-Mount Version: 2.4.32 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.196.25.250) Failed to start slapd. Attempting debug start to determine error. 502a8f8c <= mdb_index_read: failed (-30798) 502a8f8c <= mdb_index_read: failed (-30798) res_errno: 0, res_error: <>, res_matched: <> res_errno: 0, res_error: <>, res_matched: <> 502a8f8c <= mdb_index_read: failed (-30798) It gives: => ldap_dn2bv(272) <= ldap_dn2bv(uid=test1344964239966.231,ou=people,dc=zqa-128,dc=eng,dc=vmware,dc=com)=0 => ldap_bv2dn(uid=zimbra,cn=admins,cn=zimbra,0) <= ldap_bv2dn(uid=zimbra,cn=admins,cn=zimbra)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=zimbra,cn=admins,cn=zimbra)=0 => ldap_bv2dn(uid=zimbra,cn=admins,cn=zimbra,0) <= ldap_bv2dn(uid=zimbra,cn=admins,cn=zimbra)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=zimbra,cn=admins,cn=zimbra)=0 502a8fd2 => mdb_entry_get: ndn: "uid=test1344964239966.231,ou=people,dc=zqa-128,dc=eng,dc=vmware,dc=com" 502a8fd2 => mdb_entry_get: oc: "(null)", at: "(null)" => ldap_bv2dn(uid=test1344964239966.231,ou=people,dc=zqa-128,dc=eng,dc=vmware,dc=com,0) <= ldap_bv2dn(uid=test1344964239966.231,ou=people,dc=zqa-128,dc=eng,dc=vmware,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=test1344964239966.231,ou=people,dc=zqa-128,dc=eng,dc=vmware,dc=com)=0 => ldap_bv2dn(uid=test1344964239966.231,ou=people,dc=zqa-128,dc=eng,dc=vmware,dc=com,0) <= ldap_bv2dn(uid=test1344964239966.231,ou=people,dc=zqa-128,dc=eng,dc=vmware,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=test1344964239966.231,ou=people,dc=zqa-128,dc=eng,dc=vmware,dc=com)=0 502a8fd2 mdb_idl_fetch_key: 502a8fd2 mdb_idl_fetch_key: 502a8fd2 mdb_idl_fetch_key: [98599c51] 502a8fd2 mdb_idl_fetch_key: [80000000] 502a8fd2 dnMatch -4 "uid=user?^.0987,ou=people,dc=1344964239572,dc=230,dc=domain,dc=com" "uid=test1344964239966.231,ou=people,dc=zqa-128,dc=eng,dc=vmware,dc=com" 502a8fd2 dnMatch 7 "uid=distlist11344964239574,ou=people,dc=1344964239572,dc=230,dc=domain,dc=com" "uid=test1344964239966.231,ou=people,dc=zqa-128,dc=eng,dc=vmware,dc=com" 502a8fd2 dnMatch 0 "uid=test1344964239966.231,ou=people,dc=zqa-128,dc=eng,dc=vmware,dc=com" "uid=test1344964239966.231,ou=people,dc=zqa-128,dc=eng,dc=vmware,dc=com" 502a8fd2 send_ldap_result: err=0 matched="" text="" Segmentation fault (core dumped) (gdb) where #0 0x00000000004c02b8 in syncrepl_op_modify (op=0x7f60e8424490, rs=0x7f60e8423e70) at syncrepl.c:2133 #1 0x00000000004d48f4 in overlay_op_walk (op=0x7f60e8424490, rs=0x7f60e8423e70, which=op_modify, oi=0x19deb40, on=0x19de780) at backover.c:661 #2 0x00000000004d4bca in over_op_func (op=0x7f60e8424490, rs=0x7f60e8423e70, which=op_modify) at backover.c:723 #3 0x00000000004d4d35 in over_op_modify (op=0x7f60e8424490, rs=0x7f60e8423e70) at backover.c:762 #4 0x00000000004c1353 in syncrepl_message_to_op (si=0x155d340, op=0x7f60e8424490, msg=0x1926400) at syncrepl.c:2317 #5 0x00000000004bc45f in do_syncrep2 (op=0x7f60e8424490, si=0x155d340) at syncrepl.c:986 #6 0x00000000004be6ba in do_syncrepl (ctx=0x7f60e8424b50, arg=0x1afd860) at syncrepl.c:1523 #7 0x00007f88efc17cc9 in ldap_int_thread_pool_wrapper (xpool=0x14b81c0) at tpool.c:688 #8 0x00007f88ee7209ca in start_thread () from /lib/libpthread.so.0 #9 0x00007f88ee47dcdd in clone () from /lib/libc.so.6 #10 0x0000000000000000 in ?? () (gdb) list 2128 op->o_callback = sc; 2129 op->orm_no_opattrs = 1; 2130 mx->mx_orig = op->orm_modlist; 2131 mx->mx_free = newlist; 2132 for ( ml = newlist; ml; ml=ml->sml_next ) { 2133 if ( ml->sml_flags == SLAP_MOD_INTERNAL ) { 2134 ml->sml_flags = 0; 2135 ml->sml_op = SLAP_MOD_SOFTDEL; 2136 } 2137 else if ( ml->sml_op == LDAP_MOD_DELETE )

1 0

Re: (ITS#7353) Handling request controls that include spurious control values
by masarati＠aero.polimi.it 15 Aug '12

15 Aug '12

> mhardin(a)symas.com wrote: >> Some clients, like Oracle SGD, incorrectly implement the password polic= > y request >> control by including a zero-length control value with the request contr= > ol. >> OpenLDAP reports "passwordPolicyRequest control value not absent" and f= > ails the >> operation with a Protocol Error (2). While this behavior follows the le= > tter of >> RFC 4511, the control value in this case is zero-length and therefore h= > armless. >> Failing in this case seems merely punctilious, and has no real benefit.= > For >> reference, OpenLDAP 2.3 allowed a zero-length control value. > > For the very same reason I've added a work-around in upcoming python-ldap= > > 2.4.11 to handle non-decodable control response values as being absent in= > case > CRITICAL flag is False. (Apache DS 2.0.0M7 also returns such an invalid > zero-length value in password policy response control.) > > I'd appreciate to discuss a bit further whether that's the right approach= > =2E > Maybe we should take this to ietf-ldapbis mailing list as interop issue? Occasionally, we handled malformed or non-standard control values (I recall something about the many versions of the proxiedAuthz control). Our usual policy was to be "tolerant" about what comes in, possibly by requiring an explicit configuration statement to enable "tolerance" (usually, an admin knows when his system works in a broken environment, and wants to be able to decide whether being tolerant or not). So I favour allowing the administrator to explicitly enable tolerance with respect to malformed controls (my 2c). p.

1 0

Re: (ITS#7353) Handling request controls that include spurious control values
by michael＠stroeder.com 15 Aug '12

15 Aug '12

This is a cryptographically signed message in MIME format. --------------ms000806050201060707000502 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable mhardin(a)symas.com wrote: > Some clients, like Oracle SGD, incorrectly implement the password polic= y request > control by including a zero-length control value with the request contr= ol. > OpenLDAP reports "passwordPolicyRequest control value not absent" and f= ails the > operation with a Protocol Error (2). While this behavior follows the le= tter of > RFC 4511, the control value in this case is zero-length and therefore h= armless. > Failing in this case seems merely punctilious, and has no real benefit.= For > reference, OpenLDAP 2.3 allowed a zero-length control value. For the very same reason I've added a work-around in upcoming python-ldap= 2.4.11 to handle non-decodable control response values as being absent in= case CRITICAL flag is False. (Apache DS 2.0.0M7 also returns such an invalid zero-length value in password policy response control.) I'd appreciate to discuss a bit further whether that's the right approach= =2E Maybe we should take this to ietf-ldapbis mailing list as interop issue? Ciao, Michael. --------------ms000806050201060707000502 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwODE1MDcwMjE4WjAjBgkq hkiG9w0BCQQxFgQUTDuEs5JNtz2cqQb/7wx1ZxJk10QwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEASXZfP97C8zxYbux1N1U9pETszUQGUyG7GebVvdLdZnIG4r9D12JRHaFWG6YzI7ms2k/X A+CpALzsJW3LmdcT5SSH8ecfnvRMZJd9fLK6jea6UHf3gkHCNzl0EOQ/fitx0yZF92c/YN/k y07/CnMVMOw5HXRqsKw4p7SPWpUlPOtGA9zo8LnsvR9ySYGniBIWU2zC3aM3bbnsjKS/i0y2 fJ9N/MDw+sSFzm1gdiegxQNnYdDTswY89WkDVuILHYk5OXC6MOCEVyit99cpqDfxM0+VIKj/ 22hVsidJKfJ9L9FnG8/2YfcomMJF9G+qdT5m2FjDvi4MXoHyfY7Mo95QiAAAAAAAAA== --------------ms000806050201060707000502--

1 0

(ITS#7353) Handling request controls that include spurious control values
by mhardin＠symas.com 14 Aug '12

14 Aug '12

Full_Name: Matthew Hardin Version: 2.4.32 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (69.43.206.100) Some clients, like Oracle SGD, incorrectly implement the password policy request control by including a zero-length control value with the request control. OpenLDAP reports "passwordPolicyRequest control value not absent" and fails the operation with a Protocol Error (2). While this behavior follows the letter of RFC 4511, the control value in this case is zero-length and therefore harmless. Failing in this case seems merely punctilious, and has no real benefit. For reference, OpenLDAP 2.3 allowed a zero-length control value. While I don't believe it's acceptable for clients to present malformed controls, I do think it's sufficient, at least in this case, to log a warning and continue processing the request. For reference, the BER dump below shows the bind request containing the incorrectly-formatted password policy request control as well as the various stages of parsing. The request in this case comes from Oracle SGD 4.62.913. ber_get_next: tag 0x30 len 89 contents: ber_dump: buf=101fd8f00 ptr=101fd8f00 end=101fd8f59 len=89 0000: 02 01 01 60 33 02 01 03 04 27 63 6e 3d 70 70 6f ...`3....'cn=ppo 0010: 6c 69 63 79 74 73 74 2c 6f 75 3d 50 6f 6c 69 63 licytst,ou=Polic 0020: 69 65 73 2c 64 63 3d 76 73 6f 2c 64 63 3d 63 6f ies,dc=vso,dc=co 0030: 6d 80 05 61 61 61 61 61 a0 1f 30 1d 04 19 31 2e m..aaaaa..0...1. 0040: 33 2e 36 2e 31 2e 34 2e 31 2e 34 32 2e 32 2e 32 3.6.1.4.1.42.2.2 0050: 37 2e 38 2e 35 2e 31 04 00 7.8.5.1.. 502a936b op tag 0x60, time 1344967531 ber_get_next 502a936b conn=1001 op=0 do_bind ber_scanf fmt ({imt) ber: ber_dump: buf=101fd8f00 ptr=101fd8f03 end=101fd8f59 len=86 0000: 60 33 02 01 03 04 27 63 6e 3d 70 70 6f 6c 69 63 `3....'cn=ppolic 0010: 79 74 73 74 2c 6f 75 3d 50 6f 6c 69 63 69 65 73 ytst,ou=Policies 0020: 2c 64 63 3d 76 73 6f 2c 64 63 3d 63 6f 6d 80 05 ,dc=vso,dc=com.. 0030: 61 61 61 61 61 a0 1f 30 1d 04 19 31 2e 33 2e 36 aaaaa..0...1.3.6 0040: 2e 31 2e 34 2e 31 2e 34 32 2e 32 2e 32 37 2e 38 .1.4.1.42.2.27.8 0050: 2e 35 2e 31 04 00 .5.1.. ber_scanf fmt (m}) ber: ber_dump: buf=101fd8f00 ptr=101fd8f31 end=101fd8f59 len=40 0000: 00 05 61 61 61 61 61 a0 1f 30 1d 04 19 31 2e 33 ..aaaaa..0...1.3 0010: 2e 36 2e 31 2e 34 2e 31 2e 34 32 2e 32 2e 32 37 .6.1.4.1.42.2.27 0020: 2e 38 2e 35 2e 31 04 00 .8.5.1.. 502a936b => get_ctrls ber_scanf fmt ({m) ber: ber_dump: buf=101fd8f00 ptr=101fd8f3a end=101fd8f59 len=31 0000: 30 1d 04 19 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 0...1.3.6.1.4.1. 0010: 34 32 2e 32 2e 32 37 2e 38 2e 35 2e 31 04 00 42.2.27.8.5.1.. ber_scanf fmt (m) ber: ber_dump: buf=101fd8f00 ptr=101fd8f57 end=101fd8f59 len=2 0000: 00 00 .. 502a936b => get_ctrls: oid="1.3.6.1.4.1.42.2.27.8.5.1" (noncritical) 502a936b <= get_ctrls: n=1 rc=2 err="passwordPolicyRequest control value not absent" 502a936b send_ldap_result: conn=1001 op=0 p=3 502a936b send_ldap_response: msgid=1 tag=97 err=2 As an aside, the error text left me scratching my head and reading the source code to figure out what was meant. Each of the other request control handlers that doesn't require/allow a control value has a similar message. Could we change these messages to: {Warning|Error}: Spurious <control name here> control value found in request. Comments?

1 0

(ITS#7352) openldap not supporting CAMELLIA ciphers
by goodgoingswati＠gmail.com 09 Aug '12

09 Aug '12

Full_Name: Swati Version: 2.4.32 OS: RHEL5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (115.113.153.34) openldap is not supporting CAMELLIA based ciphers(both RSA and DSA based) I have configured SSL LDAP(LDAPS) and on checking SSL connection with LDAPS server with CAMELLIA based cipher leads to failure in handshake: openssl s_client -connect localhost:636 -showcerts -cipher DHE-DSS-CAMELLIA256-SHA -state -CAfile /path_to_cert -cert /path_to_client_cert -key /path_to_client_key CONNECTED(00000003) SSL_connect:before/connect initialization SSL_connect:SSLv2/v3 write client hello A SSL3 alert read:fatal:handshake failure SSL_connect:error in SSLv2/v3 read server hello A 47726707455072:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:741: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 102 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE Handshake is failing with all camellia ciphers.

1 0

(ITS#7351) can not start slapd when enable accesslog relay
by bashift＠gmail.com 09 Aug '12

09 Aug '12

Full_Name: ChenShuJun Version: 2.4.32 OS: RHEL5.5(2.6.18-194.el5) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (218.246.127.3) [root@LDAP_LAB_A openldap]# slapd -d 1 ldap_url_parse_ext(ldap://localhost/) ldap_init: trying /usr/local/openldap-2.4.32/etc/openldap/ldap.conf ldap_init: using /usr/local/openldap-2.4.32/etc/openldap/ldap.conf ldap_init: HOME env is /root ldap_init: trying /root/ldaprc ldap_init: trying /root/.ldaprc ldap_init: trying ldaprc ldap_init: LDAPCONF env is NULL ldap_init: LDAPRC env is NULL 502475bb @(#) $OpenLDAP: slapd 2.4.32 (Aug 8 2012 14:19:37) $ root@LDAP_LAB_A.bgctv.net.cn:/root/openldap-2.4.32/servers/slapd ldap_pvt_gethostbyname_a: host=LDAP_LAB_A.bgctv.net.cn, r=11 502475bb daemon_init: listen on ldap:/// 502475bb daemon_init: 1 listeners to open... ldap_url_parse_ext(ldap:///) 502475bb daemon: listener initialized ldap:/// 502475bb daemon_init: 1 listeners opened ldap_create 502475bb slapd init: initiated server. 502475bb slap_sasl_init: initialized! 502475bb bdb_back_initialize: initialize BDB backend 502475bb bdb_back_initialize: Berkeley DB 4.8.30: (April 9, 2010) 502475bb hdb_back_initialize: initialize HDB backend 502475bb hdb_back_initialize: Berkeley DB 4.8.30: (April 9, 2010) 502475bb mdb_back_initialize: initialize MDB backend 502475bb mdb_back_initialize: MDB 0.9.0: ("September 1, 2011") 502475bb ndb_back_initialize: initialize ndb backend 502475bb null_back_initialize: initialize null backend 502475bb perl backend open 502475bb ==> translucent_initialize 502475bb ndb_db_init: Initializing ndb database 502475bb >>> dnPrettyNormal: <dc=bgctv,dc=net,dc=cn> 502475bb <<< dnPrettyNormal: <dc=bgctv,dc=net,dc=cn>, <dc=bgctv,dc=net,dc=cn> 502475bb >>> dnPrettyNormal: <cn=admin,dc=bgctv,dc=net,dc=cn> 502475bb <<< dnPrettyNormal: <cn=admin,dc=bgctv,dc=net,dc=cn>, <cn=admin,dc=bgctv,dc=net,dc=cn> 502475bb >>> dnPrettyNormal: <cn=auditlog> 502475bb <<< dnPrettyNormal: <cn=auditlog>, <cn=auditlog> put_filter: "(objectclass=*)" put_filter: simple put_simple_filter: "objectclass=*" ber_scanf fmt (m) ber: 502475bb >>> dnNormalize: <ou=cm,dc=bgctv,dc=net,dc=cn> 502475bb <<< dnNormalize: <ou=cm,dc=bgctv,dc=net,dc=cn> 502475bb >>> dnNormalize: <userid=cmadmin,dc=bgctv,dc=net,dc=cn> 502475bb <<< dnNormalize: <uid=cmadmin,dc=bgctv,dc=net,dc=cn> 502475bb >>> dnNormalize: <userid=cmadmin,dc=bgctv,dc=net,dc=cn> 502475bb <<< dnNormalize: <uid=cmadmin,dc=bgctv,dc=net,dc=cn> 502475bb bdb_db_init: Initializing BDB database 502475bb >>> dnPrettyNormal: <cn=auditlog> 502475bb <<< dnPrettyNormal: <cn=auditlog>, <cn=auditlog> 502475bb >>> dnPrettyNormal: <cn=admin,cn=auditlog> 502475bb <<< dnPrettyNormal: <cn=admin,cn=auditlog>, <cn=admin,cn=auditlog> 502475bb >>> dnNormalize: <cn=Subschema> 502475bb <<< dnNormalize: <cn=subschema> 502475bb matching_rule_use_init 502475bb 1.2.840.113556.1.4.804 (integerBitOrMatch): 502475bb matchingRuleUse: ( 1.2.840.113556.1.4.804 NAME 'integerBitOrMatch' APPLIES ( supportedLDAPVersion $ entryTtl $ uidNumber $ gidNumber $ olcConcurrency $ olcConnMaxPending $ olcConnMaxPendingAuth $ olcIdleTimeout $ olcIndexSubstrIfMinLen $ olcIndexSubstrIfMaxLen $ olcIndexSubstrAnyLen $ olcIndexSubstrAnyStep $ olcIndexIntLen $ olcListenerThreads $ olcLocalSSF $ olcMaxDerefDepth $ olcReplicationInterval $ olcSockbufMaxIncoming $ olcSockbufMaxIncomingAuth $ olcThreads $ olcToolThreads $ olcWriteTimeout $ olcDbCacheFree $ olcDbCacheSize $ olcDbDNcacheSize $ olcDbIDLcacheSize $ olcDbSearchStack $ olcDbShmKey $ olcDbProtocolVersion $ olcDbConnectionPoolMax $ olcChainMaxReferralDepth $ olcDbMaxReaders $ olcDbMaxSize $ olcDbPort $ olcDbFlag $ olcDbConnections $ olcDDSmaxDynamicObjects $ olcPcacheMaxQueries $ olcRetcodeSleep $ olcSssVlvMax $ olcSssVlvMaxKeys $ olcSssVlvMaxPerConn $ olcSpSessionlog $ mailPreferenceOption $ shadowLastChange $ shadowMin $ shadowMax $ shadowWarning $ shadowInactive $ shadowExpire $ shadowFlag $ ipServicePort $ ipProtocolNumber $ oncRpcNumber ) ) 502475bb 1.2.840.113556.1.4.803 (integerBitAndMatch): 502475bb matchingRuleUse: ( 1.2.840.113556.1.4.803 NAME 'integerBitAndMatch' APPLIES ( supportedLDAPVersion $ entryTtl $ uidNumber $ gidNumber $ olcConcurrency $ olcConnMaxPending $ olcConnMaxPendingAuth $ olcIdleTimeout $ olcIndexSubstrIfMinLen $ olcIndexSubstrIfMaxLen $ olcIndexSubstrAnyLen $ olcIndexSubstrAnyStep $ olcIndexIntLen $ olcListenerThreads $ olcLocalSSF $ olcMaxDerefDepth $ olcReplicationInterval $ olcSockbufMaxIncoming $ olcSockbufMaxIncomingAuth $ olcThreads $ olcToolThreads $ olcWriteTimeout $ olcDbCacheFree $ olcDbCacheSize $ olcDbDNcacheSize $ olcDbIDLcacheSize $ olcDbSearchStack $ olcDbShmKey $ olcDbProtocolVersion $ olcDbConnectionPoolMax $ olcChainMaxReferralDepth $ olcDbMaxReaders $ olcDbMaxSize $ olcDbPort $ olcDbFlag $ olcDbConnections $ olcDDSmaxDynamicObjects $ olcPcacheMaxQueries $ olcRetcodeSleep $ olcSssVlvMax $ olcSssVlvMaxKeys $ olcSssVlvMaxPerConn $ olcSpSessionlog $ mailPreferenceOption $ shadowLastChange $ shadowMin $ shadowMax $ shadowWarning $ shadowInactive $ shadowExpire $ shadowFlag $ ipServicePort $ ipProtocolNumber $ oncRpcNumber ) ) 502475bb 1.3.6.1.4.1.1466.109.114.2 (caseIgnoreIA5Match): 502475bb matchingRuleUse: ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' APPLIES ( altServer $ olcDbConfig $ c $ mail $ dc $ associatedDomain $ email $ aRecord $ mDRecord $ mXRecord $ nSRecord $ sOARecord $ cNAMERecord $ janetMailbox $ gecos $ homeDirectory $ loginShell $ memberUid $ memberNisNetgroup $ ipHostNumber $ ipNetworkNumber $ ipNetmaskNumber $ macAddress $ bootFile $ nisMapEntry ) ) 502475bb 1.3.6.1.4.1.1466.109.114.1 (caseExactIA5Match): 502475bb matchingRuleUse: ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' APPLIES ( altServer $ olcDbConfig $ c $ mail $ dc $ associatedDomain $ email $ aRecord $ mDRecord $ mXRecord $ nSRecord $ sOARecord $ cNAMERecord $ janetMailbox $ gecos $ homeDirectory $ loginShell $ memberUid $ memberNisNetgroup $ ipHostNumber $ ipNetworkNumber $ ipNetmaskNumber $ macAddress $ bootFile $ nisMapEntry ) ) 502475bb 2.5.13.39 (certificateListMatch): 502475bb 2.5.13.38 (certificateListExactMatch): 502475bb matchingRuleUse: ( 2.5.13.38 NAME 'certificateListExactMatch' APPLIES ( authorityRevocationList $ certificateRevocationList $ deltaRevocationList ) ) 502475bb 2.5.13.35 (certificateMatch): 502475bb 2.5.13.34 (certificateExactMatch): 502475bb matchingRuleUse: ( 2.5.13.34 NAME 'certificateExactMatch' APPLIES ( userCertificate $ cACertificate ) ) 502475bb 2.5.13.30 (objectIdentifierFirstComponentMatch): 502475bb matchingRuleUse: ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch' APPLIES ( supportedControl $ supportedExtension $ supportedFeatures $ ldapSyntaxes $ supportedApplicationContext ) ) 502475bb 2.5.13.29 (integerFirstComponentMatch): 502475bb matchingRuleUse: ( 2.5.13.29 NAME 'integerFirstComponentMatch' APPLIES ( supportedLDAPVersion $ entryTtl $ uidNumber $ gidNumber $ olcConcurrency $ olcConnMaxPending $ olcConnMaxPendingAuth $ olcIdleTimeout $ olcIndexSubstrIfMinLen $ olcIndexSubstrIfMaxLen $ olcIndexSubstrAnyLen $ olcIndexSubstrAnyStep $ olcIndexIntLen $ olcListenerThreads $ olcLocalSSF $ olcMaxDerefDepth $ olcReplicationInterval $ olcSockbufMaxIncoming $ olcSockbufMaxIncomingAuth $ olcThreads $ olcToolThreads $ olcWriteTimeout $ olcDbCacheFree $ olcDbCacheSize $ olcDbDNcacheSize $ olcDbIDLcacheSize $ olcDbSearchStack $ olcDbShmKey $ olcDbProtocolVersion $ olcDbConnectionPoolMax $ olcChainMaxReferralDepth $ olcDbMaxReaders $ olcDbMaxSize $ olcDbPort $ olcDbFlag $ olcDbConnections $ olcDDSmaxDynamicObjects $ olcPcacheMaxQueries $ olcRetcodeSleep $ olcSssVlvMax $ olcSssVlvMaxKeys $ olcSssVlvMaxPerConn $ olcSpSessionlog $ mailPreferenceOption $ shadowLastChange $ shadowMin $ shadowMax $ shadowWarning $ shadowInactive $ shadowExpire $ shadowFlag $ ipServicePort $ ipProtocolNumber $ oncRpcNumber ) ) 502475bb 2.5.13.28 (generalizedTimeOrderingMatch): 502475bb matchingRuleUse: ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch' APPLIES ( createTimestamp $ modifyTimestamp $ pwdChangedTime $ pwdAccountLockedTime $ pwdFailureTime $ pwdGraceUseTime ) ) 502475bb 2.5.13.27 (generalizedTimeMatch): 502475bb matchingRuleUse: ( 2.5.13.27 NAME 'generalizedTimeMatch' APPLIES ( createTimestamp $ modifyTimestamp $ pwdChangedTime $ pwdAccountLockedTime $ pwdFailureTime $ pwdGraceUseTime ) ) 502475bb 2.5.13.24 (protocolInformationMatch): 502475bb matchingRuleUse: ( 2.5.13.24 NAME 'protocolInformationMatch' APPLIES protocolInformation ) 502475bb 2.5.13.23 (uniqueMemberMatch): 502475bb matchingRuleUse: ( 2.5.13.23 NAME 'uniqueMemberMatch' APPLIES uniqueMember ) 502475bb 2.5.13.22 (presentationAddressMatch): 502475bb matchingRuleUse: ( 2.5.13.22 NAME 'presentationAddressMatch' APPLIES presentationAddress ) 502475bb 2.5.13.20 (telephoneNumberMatch): 502475bb matchingRuleUse: ( 2.5.13.20 NAME 'telephoneNumberMatch' APPLIES ( telephoneNumber $ homePhone $ mobile $ pager ) ) 502475bb 2.5.13.18 (octetStringOrderingMatch): 502475bb matchingRuleUse: ( 2.5.13.18 NAME 'octetStringOrderingMatch' APPLIES ( userPassword $ olcDbCryptKey $ pwdHistory ) ) 502475bb 2.5.13.17 (octetStringMatch): 502475bb matchingRuleUse: ( 2.5.13.17 NAME 'octetStringMatch' APPLIES ( userPassword $ olcDbCryptKey $ pwdHistory ) ) 502475bb 2.5.13.16 (bitStringMatch): 502475bb matchingRuleUse: ( 2.5.13.16 NAME 'bitStringMatch' APPLIES x500UniqueIdentifier ) 502475bb 2.5.13.15 (integerOrderingMatch): 502475bb matchingRuleUse: ( 2.5.13.15 NAME 'integerOrderingMatch' APPLIES ( supportedLDAPVersion $ entryTtl $ uidNumber $ gidNumber $ olcConcurrency $ olcConnMaxPending $ olcConnMaxPendingAuth $ olcIdleTimeout $ olcIndexSubstrIfMinLen $ olcIndexSubstrIfMaxLen $ olcIndexSubstrAnyLen $ olcIndexSubstrAnyStep $ olcIndexIntLen $ olcListenerThreads $ olcLocalSSF $ olcMaxDerefDepth $ olcReplicationInterval $ olcSockbufMaxIncoming $ olcSockbufMaxIncomingAuth $ olcThreads $ olcToolThreads $ olcWriteTimeout $ olcDbCacheFree $ olcDbCacheSize $ olcDbDNcacheSize $ olcDbIDLcacheSize $ olcDbSearchStack $ olcDbShmKey $ olcDbProtocolVersion $ olcDbConnectionPoolMax $ olcChainMaxReferralDepth $ olcDbMaxReaders $ olcDbMaxSize $ olcDbPort $ olcDbFlag $ olcDbConnections $ olcDDSmaxDynamicObjects $ olcPcacheMaxQueries $ olcRetcodeSleep $ olcSssVlvMax $ olcSssVlvMaxKeys $ olcSssVlvMaxPerConn $ olcSpSessionlog $ mailPreferenceOption $ shadowLastChange $ shadowMin $ shadowMax $ shadowWarning $ shadowInactive $ shadowExpire $ shadowFlag $ ipServicePort $ ipProtocolNumber $ oncRpcNumber ) ) 502475bb 2.5.13.14 (integerMatch): 502475bb matchingRuleUse: ( 2.5.13.14 NAME 'integerMatch' APPLIES ( supportedLDAPVersion $ entryTtl $ uidNumber $ gidNumber $ olcConcurrency $ olcConnMaxPending $ olcConnMaxPendingAuth $ olcIdleTimeout $ olcIndexSubstrIfMinLen $ olcIndexSubstrIfMaxLen $ olcIndexSubstrAnyLen $ olcIndexSubstrAnyStep $ olcIndexIntLen $ olcListenerThreads $ olcLocalSSF $ olcMaxDerefDepth $ olcReplicationInterval $ olcSockbufMaxIncoming $ olcSockbufMaxIncomingAuth $ olcThreads $ olcToolThreads $ olcWriteTimeout $ olcDbCacheFree $ olcDbCacheSize $ olcDbDNcacheSize $ olcDbIDLcacheSize $ olcDbSearchStack $ olcDbShmKey $ olcDbProtocolVersion $ olcDbConnectionPoolMax $ olcChainMaxReferralDepth $ olcDbMaxReaders $ olcDbMaxSize $ olcDbPort $ olcDbFlag $ olcDbConnections $ olcDDSmaxDynamicObjects $ olcPcacheMaxQueries $ olcRetcodeSleep $ olcSssVlvMax $ olcSssVlvMaxKeys $ olcSssVlvMaxPerConn $ olcSpSessionlog $ mailPreferenceOption $ shadowLastChange $ shadowMin $ shadowMax $ shadowWarning $ shadowInactive $ shadowExpire $ shadowFlag $ ipServicePort $ ipProtocolNumber $ oncRpcNumber ) ) 502475bb 2.5.13.13 (booleanMatch): 502475bb matchingRuleUse: ( 2.5.13.13 NAME 'booleanMatch' APPLIES ( hasSubordinates $ olcAddContentAcl $ olcGentleHUP $ olcHidden $ olcLastMod $ olcMirrorMode $ olcMonitoring $ olcReadOnly $ olcReverseLookup $ olcSyncUseSubentry $ olcDbChecksum $ olcDbNoSync $ olcDbDirtyRead $ olcDbLinearIndex $ olcDbRebindAsUser $ olcDbChaseReferrals $ olcDbProxyWhoAmI $ olcDbSingleConn $ olcDbUseTemporaryConn $ olcDbSessionTrackingRequest $ olcDbNoRefs $ olcDbNoUndefFilter $ olcChainCacheURI $ olcChainReturnError $ olcDbBindAllowed $ olcPerlFilterSearchResults $ olcAccessLogSuccess $ olcDDSstate $ olcMemberOfRefInt $ pwdReset $ olcPPolicyHashCleartext $ olcPPolicyForwardUpdates $ olcPPolicyUseLockout $ olcPcachePersist $ olcPcacheValidate $ olcPcacheOffline $ olcRetcodeInDir $ olcRwmNormalizeMapped $ olcRwmDropUnrequested $ olcSpNoPresent $ olcSpReloadHint $ olcTranslucentStrict $ olcTranslucentNoGlue $ olcTranslucentBindLocal $ olcTranslucentPwModLocal $ olcUniqueStrict ) ) 502475bb 2.5.13.11 (caseIgnoreListMatch): 502475bb matchingRuleUse: ( 2.5.13.11 NAME 'caseIgnoreListMatch' APPLIES ( postalAddress $ registeredAddress $ homePostalAddress ) ) 502475bb 2.5.13.9 (numericStringOrderingMatch): 502475bb matchingRuleUse: ( 2.5.13.9 NAME 'numericStringOrderingMatch' APPLIES ( x121Address $ internationaliSDNNumber ) ) 502475bb 2.5.13.8 (numericStringMatch): 502475bb matchingRuleUse: ( 2.5.13.8 NAME 'numericStringMatch' APPLIES ( x121Address $ internationaliSDNNumber ) ) 502475bb 2.5.13.7 (caseExactSubstringsMatch): 502475bb matchingRuleUse: ( 2.5.13.7 NAME 'caseExactSubstringsMatch' APPLIES ( serialNumber $ destinationIndicator $ dnQualifier ) ) 502475bb 2.5.13.6 (caseExactOrderingMatch): 502475bb matchingRuleUse: ( 2.5.13.6 NAME 'caseExactOrderingMatch' APPLIES ( supportedSASLMechanisms $ vendorName $ vendorVersion $ ref $ name $ cn $ uid $ labeledURI $ description $ olcConfigFile $ olcConfigDir $ olcAccess $ olcAllows $ olcArgsFile $ olcAttributeOptions $ olcAttributeTypes $ olcAuthIDRewrite $ olcAuthzPolicy $ olcAuthzRegexp $ olcBackend $ olcDatabase $ olcDisallows $ olcDitContentRules $ olcExtraAttrs $ olcInclude $ olcLdapSyntaxes $ olcLimits $ olcLogFile $ olcLogLevel $ olcModuleLoad $ olcModulePath $ olcObjectClasses $ olcObjectIdentifier $ olcOverlay $ olcPasswordCryptSaltFormat $ olcPasswordHash $ olcPidFile $ olcPlugin $ olcPluginLogFile $ olcReferral $ olcReplica $ olcReplicaArgsFile $ olcReplicaPidFile $ olcReplogFile $ olcRequires $ olcRestrict $ olcRootDSE $ olcRootPW $ olcSaslAuxprops $ olcSaslHost $ olcSaslRealm $ olcSaslSecProps $ olcSecurity $ olcServerID $ olcSizeLimit $ olcSortVals $ olcSubordinate $ olcSyncrepl $ olcTCPBuffer $ olcTimeLimit $ olcTLSCACertificateFile $ olcTLSCACertificatePath $ olcTLSCertificateFile $ olcTLSCertificateKeyFile $ olcTLSCipherSuite $ olcTLSCRLCheck $ olcTLSCRLFile $ olcTLSRandFile $ olcTLSVerifyClient $ olcTLSDHParamFile $ olcTLSProtocolMin $ olcUpdateRef $ olcDbDirectory $ olcDbCheckpoint $ olcDbCryptFile $ olcDbPageSize $ olcDbIndex $ olcDbLockDetect $ olcDbMode $ olcDbURI $ olcDbStartTLS $ olcDbACLPasswd $ olcDbACLBind $ olcDbIDAssertPasswd $ olcDbIDAssertBind $ olcDbIDAssertMode $ olcDbIDAssertAuthzFrom $ olcDbTFSupport $ olcDbTimeout $ olcDbIdleTimeout $ olcDbConnTtl $ olcDbNetworkTimeout $ olcDbCancel $ olcDbQuarantine $ olcDbIDAssertPassThru $ olcChainingBehavior $ olcDbHost $ olcDbName $ olcDbUser $ olcDbPass $ olcDbSocket $ olcDbConnect $ olcNdbAttrLen $ olcNdbAttrSet $ olcNdbAttrBlob $ olcPasswdFile $ olcPerlModule $ olcPerlModulePath $ olcPerlModuleConfig $ olcShellBind $ olcShellUnbind $ olcShellSearch $ olcShellCompare $ olcShellModify $ olcShellModRDN $ olcShellAdd $ olcShellDelete $ olcOvSocketOps $ olcOvSocketResps $ olcDbSocketPath $ olcDbSocketExtensions $ olcAccessLogOps $ olcAccessLogPurge $ olcAccessLogOld $ olcAccessLogOldAttr $ olcAccessLogBase $ olcAuditlogFile $ olcCollectInfo $ olcConstraintAttribute $ olcDDSmaxTtl $ olcDDSminTtl $ olcDDSdefaultTtl $ olcDDSinterval $ olcDDStolerance $ olcDGAttrPair $ olcDlAttrSet $ olcMemberOfDangling $ olcMemberOfGroupOC $ olcMemberOfMemberAD $ olcMemberOfMemberOfAD $ olcMemberOfDanglingError $ olcPcache $ olcPcacheAttrset $ olcPcacheTemplate $ olcPcachePosition $ olcPcacheBind $ olcRefintAttribute $ olcRetcodeItem $ olcRwmRewrite $ olcRwmTFSupport $ olcRwmMap $ olcSpCheckpoint $ olcTranslucentLocal $ olcTranslucentRemote $ olcUniqueIgnore $ olcUniqueAttribute $ olcUniqueURI $ olcValSortAttr $ knowledgeInformation $ sn $ serialNumber $ c $ l $ st $ street $ o $ ou $ title $ businessCategory $ postalCode $ postOfficeBox $ physicalDeliveryOfficeName $ destinationIndicator $ givenName $ initials $ generationQualifier $ dnQualifier $ houseIdentifier $ dmdName $ pseudonym $ textEncodedORAddress $ info $ drink $ roomNumber $ userClass $ host $ documentIdentifier $ documentTitle $ documentVersion $ documentLocation $ personalTitle $ co $ uniqueIdentifier $ organizationalStatus $ buildingName $ documentPublisher $ ipServiceProtocol $ nisMapName $ carLicense $ departmentNumber $ displayName $ employeeNumber $ employeeType $ preferredLanguage $ cmmac $ cmipadd $ servicelevel $ startdate $ enddate $ cmuid $ cmext1 $ cmext2 $ cmext3 $ cmext4 $ cmext5 $ cmext6 $ cmext7 $ cmext8 $ cmext9 ) ) 502475bb 2.5.13.5 (caseExactMatch): 502475bb matchingRuleUse: ( 2.5.13.5 NAME 'caseExactMatch' APPLIES ( supportedSASLMechanisms $ vendorName $ vendorVersion $ ref $ name $ cn $ uid $ labeledURI $ description $ olcConfigFile $ olcConfigDir $ olcAccess $ olcAllows $ olcArgsFile $ olcAttributeOptions $ olcAttributeTypes $ olcAuthIDRewrite $ olcAuthzPolicy $ olcAuthzRegexp $ olcBackend $ olcDatabase $ olcDisallows $ olcDitContentRules $ olcExtraAttrs $ olcInclude $ olcLdapSyntaxes $ olcLimits $ olcLogFile $ olcLogLevel $ olcModuleLoad $ olcModulePath $ olcObjectClasses $ olcObjectIdentifier $ olcOverlay $ olcPasswordCryptSaltFormat $ olcPasswordHash $ olcPidFile $ olcPlugin $ olcPluginLogFile $ olcReferral $ olcReplica $ olcReplicaArgsFile $ olcReplicaPidFile $ olcReplogFile $ olcRequires $ olcRestrict $ olcRootDSE $ olcRootPW $ olcSaslAuxprops $ olcSaslHost $ olcSaslRealm $ olcSaslSecProps $ olcSecurity $ olcServerID $ olcSizeLimit $ olcSortVals $ olcSubordinate $ olcSyncrepl $ olcTCPBuffer $ olcTimeLimit $ olcTLSCACertificateFile $ olcTLSCACertificatePath $ olcTLSCertificateFile $ olcTLSCertificateKeyFile $ olcTLSCipherSuite $ olcTLSCRLCheck $ olcTLSCRLFile $ olcTLSRandFile $ olcTLSVerifyClient $ olcTLSDHParamFile $ olcTLSProtocolMin $ olcUpdateRef $ olcDbDirectory $ olcDbCheckpoint $ olcDbCryptFile $ olcDbPageSize $ olcDbIndex $ olcDbLockDetect $ olcDbMode $ olcDbURI $ olcDbStartTLS $ olcDbACLPasswd $ olcDbACLBind $ olcDbIDAssertPasswd $ olcDbIDAssertBind $ olcDbIDAssertMode $ olcDbIDAssertAuthzFrom $ olcDbTFSupport $ olcDbTimeout $ olcDbIdleTimeout $ olcDbConnTtl $ olcDbNetworkTimeout $ olcDbCancel $ olcDbQuarantine $ olcDbIDAssertPassThru $ olcChainingBehavior $ olcDbHost $ olcDbName $ olcDbUser $ olcDbPass $ olcDbSocket $ olcDbConnect $ olcNdbAttrLen $ olcNdbAttrSet $ olcNdbAttrBlob $ olcPasswdFile $ olcPerlModule $ olcPerlModulePath $ olcPerlModuleConfig $ olcShellBind $ olcShellUnbind $ olcShellSearch $ olcShellCompare $ olcShellModify $ olcShellModRDN $ olcShellAdd $ olcShellDelete $ olcOvSocketOps $ olcOvSocketResps $ olcDbSocketPath $ olcDbSocketExtensions $ olcAccessLogOps $ olcAccessLogPurge $ olcAccessLogOld $ olcAccessLogOldAttr $ olcAccessLogBase $ olcAuditlogFile $ olcCollectInfo $ olcConstraintAttribute $ olcDDSmaxTtl $ olcDDSminTtl $ olcDDSdefaultTtl $ olcDDSinterval $ olcDDStolerance $ olcDGAttrPair $ olcDlAttrSet $ olcMemberOfDangling $ olcMemberOfGroupOC $ olcMemberOfMemberAD $ olcMemberOfMemberOfAD $ olcMemberOfDanglingError $ olcPcache $ olcPcacheAttrset $ olcPcacheTemplate $ olcPcachePosition $ olcPcacheBind $ olcRefintAttribute $ olcRetcodeItem $ olcRwmRewrite $ olcRwmTFSupport $ olcRwmMap $ olcSpCheckpoint $ olcTranslucentLocal $ olcTranslucentRemote $ olcUniqueIgnore $ olcUniqueAttribute $ olcUniqueURI $ olcValSortAttr $ knowledgeInformation $ sn $ serialNumber $ c $ l $ st $ street $ o $ ou $ title $ businessCategory $ postalCode $ postOfficeBox $ physicalDeliveryOfficeName $ destinationIndicator $ givenName $ initials $ generationQualifier $ dnQualifier $ houseIdentifier $ dmdName $ pseudonym $ textEncodedORAddress $ info $ drink $ roomNumber $ userClass $ host $ documentIdentifier $ documentTitle $ documentVersion $ documentLocation $ personalTitle $ co $ uniqueIdentifier $ organizationalStatus $ buildingName $ documentPublisher $ ipServiceProtocol $ nisMapName $ carLicense $ departmentNumber $ displayName $ employeeNumber $ employeeType $ preferredLanguage $ cmmac $ cmipadd $ servicelevel $ startdate $ enddate $ cmuid $ cmext1 $ cmext2 $ cmext3 $ cmext4 $ cmext5 $ cmext6 $ cmext7 $ cmext8 $ cmext9 ) ) 502475bc 2.5.13.4 (caseIgnoreSubstringsMatch): 502475bc matchingRuleUse: ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' APPLIES ( serialNumber $ destinationIndicator $ dnQualifier ) ) 502475bc 2.5.13.3 (caseIgnoreOrderingMatch): 502475bc matchingRuleUse: ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch' APPLIES ( supportedSASLMechanisms $ vendorName $ vendorVersion $ ref $ name $ cn $ uid $ labeledURI $ description $ olcConfigFile $ olcConfigDir $ olcAccess $ olcAllows $ olcArgsFile $ olcAttributeOptions $ olcAttributeTypes $ olcAuthIDRewrite $ olcAuthzPolicy $ olcAuthzRegexp $ olcBackend $ olcDatabase $ olcDisallows $ olcDitContentRules $ olcExtraAttrs $ olcInclude $ olcLdapSyntaxes $ olcLimits $ olcLogFile $ olcLogLevel $ olcModuleLoad $ olcModulePath $ olcObjectClasses $ olcObjectIdentifier $ olcOverlay $ olcPasswordCryptSaltFormat $ olcPasswordHash $ olcPidFile $ olcPlugin $ olcPluginLogFile $ olcReferral $ olcReplica $ olcReplicaArgsFile $ olcReplicaPidFile $ olcReplogFile $ olcRequires $ olcRestrict $ olcRootDSE $ olcRootPW $ olcSaslAuxprops $ olcSaslHost $ olcSaslRealm $ olcSaslSecProps $ olcSecurity $ olcServerID $ olcSizeLimit $ olcSortVals $ olcSubordinate $ olcSyncrepl $ olcTCPBuffer $ olcTimeLimit $ olcTLSCACertificateFile $ olcTLSCACertificatePath $ olcTLSCertificateFile $ olcTLSCertificateKeyFile $ olcTLSCipherSuite $ olcTLSCRLCheck $ olcTLSCRLFile $ olcTLSRandFile $ olcTLSVerifyClient $ olcTLSDHParamFile $ olcTLSProtocolMin $ olcUpdateRef $ olcDbDirectory $ olcDbCheckpoint $ olcDbCryptFile $ olcDbPageSize $ olcDbIndex $ olcDbLockDetect $ olcDbMode $ olcDbURI $ olcDbStartTLS $ olcDbACLPasswd $ olcDbACLBind $ olcDbIDAssertPasswd $ olcDbIDAssertBind $ olcDbIDAssertMode $ olcDbIDAssertAuthzFrom $ olcDbTFSupport $ olcDbTimeout $ olcDbIdleTimeout $ olcDbConnTtl $ olcDbNetworkTimeout $ olcDbCancel $ olcDbQuarantine $ olcDbIDAssertPassThru $ olcChainingBehavior $ olcDbHost $ olcDbName $ olcDbUser $ olcDbPass $ olcDbSocket $ olcDbConnect $ olcNdbAttrLen $ olcNdbAttrSet $ olcNdbAttrBlob $ olcPasswdFile $ olcPerlModule $ olcPerlModulePath $ olcPerlModuleConfig $ olcShellBind $ olcShellUnbind $ olcShellSearch $ olcShellCompare $ olcShellModify $ olcShellModRDN $ olcShellAdd $ olcShellDelete $ olcOvSocketOps $ olcOvSocketResps $ olcDbSocketPath $ olcDbSocketExtensions $ olcAccessLogOps $ olcAccessLogPurge $ olcAccessLogOld $ olcAccessLogOldAttr $ olcAccessLogBase $ olcAuditlogFile $ olcCollectInfo $ olcConstraintAttribute $ olcDDSmaxTtl $ olcDDSminTtl $ olcDDSdefaultTtl $ olcDDSinterval $ olcDDStolerance $ olcDGAttrPair $ olcDlAttrSet $ olcMemberOfDangling $ olcMemberOfGroupOC $ olcMemberOfMemberAD $ olcMemberOfMemberOfAD $ olcMemberOfDanglingError $ olcPcache $ olcPcacheAttrset $ olcPcacheTemplate $ olcPcachePosition $ olcPcacheBind $ olcRefintAttribute $ olcRetcodeItem $ olcRwmRewrite $ olcRwmTFSupport $ olcRwmMap $ olcSpCheckpoint $ olcTranslucentLocal $ olcTranslucentRemote $ olcUniqueIgnore $ olcUniqueAttribute $ olcUniqueURI $ olcValSortAttr $ knowledgeInformation $ sn $ serialNumber $ c $ l $ st $ street $ o $ ou $ title $ businessCategory $ postalCode $ postOfficeBox $ physicalDeliveryOfficeName $ destinationIndicator $ givenName $ initials $ generationQualifier $ dnQualifier $ houseIdentifier $ dmdName $ pseudonym $ textEncodedORAddress $ info $ drink $ roomNumber $ userClass $ host $ documentIdentifier $ documentTitle $ documentVersion $ documentLocation $ personalTitle $ co $ uniqueIdentifier $ organizationalStatus $ buildingName $ documentPublisher $ ipServiceProtocol $ nisMapName $ carLicense $ departmentNumber $ displayName $ employeeNumber $ employeeType $ preferredLanguage $ cmmac $ cmipadd $ servicelevel $ startdate $ enddate $ cmuid $ cmext1 $ cmext2 $ cmext3 $ cmext4 $ cmext5 $ cmext6 $ cmext7 $ cmext8 $ cmext9 ) ) 502475bc 2.5.13.2 (caseIgnoreMatch): 502475bc matchingRuleUse: ( 2.5.13.2 NAME 'caseIgnoreMatch' APPLIES ( supportedSASLMechanisms $ vendorName $ vendorVersion $ ref $ name $ cn $ uid $ labeledURI $ description $ olcConfigFile $ olcConfigDir $ olcAccess $ olcAllows $ olcArgsFile $ olcAttributeOptions $ olcAttributeTypes $ olcAuthIDRewrite $ olcAuthzPolicy $ olcAuthzRegexp $ olcBackend $ olcDatabase $ olcDisallows $ olcDitContentRules $ olcExtraAttrs $ olcInclude $ olcLdapSyntaxes $ olcLimits $ olcLogFile $ olcLogLevel $ olcModuleLoad $ olcModulePath $ olcObjectClasses $ olcObjectIdentifier $ olcOverlay $ olcPasswordCryptSaltFormat $ olcPasswordHash $ olcPidFile $ olcPlugin $ olcPluginLogFile $ olcReferral $ olcReplica $ olcReplicaArgsFile $ olcReplicaPidFile $ olcReplogFile $ olcRequires $ olcRestrict $ olcRootDSE $ olcRootPW $ olcSaslAuxprops $ olcSaslHost $ olcSaslRealm $ olcSaslSecProps $ olcSecurity $ olcServerID $ olcSizeLimit $ olcSortVals $ olcSubordinate $ olcSyncrepl $ olcTCPBuffer $ olcTimeLimit $ olcTLSCACertificateFile $ olcTLSCACertificatePath $ olcTLSCertificateFile $ olcTLSCertificateKeyFile $ olcTLSCipherSuite $ olcTLSCRLCheck $ olcTLSCRLFile $ olcTLSRandFile $ olcTLSVerifyClient $ olcTLSDHParamFile $ olcTLSProtocolMin $ olcUpdateRef $ olcDbDirectory $ olcDbCheckpoint $ olcDbCryptFile $ olcDbPageSize $ olcDbIndex $ olcDbLockDetect $ olcDbMode $ olcDbURI $ olcDbStartTLS $ olcDbACLPasswd $ olcDbACLBind $ olcDbIDAssertPasswd $ olcDbIDAssertBind $ olcDbIDAssertMode $ olcDbIDAssertAuthzFrom $ olcDbTFSupport $ olcDbTimeout $ olcDbIdleTimeout $ olcDbConnTtl $ olcDbNetworkTimeout $ olcDbCancel $ olcDbQuarantine $ olcDbIDAssertPassThru $ olcChainingBehavior $ olcDbHost $ olcDbName $ olcDbUser $ olcDbPass $ olcDbSocket $ olcDbConnect $ olcNdbAttrLen $ olcNdbAttrSet $ olcNdbAttrBlob $ olcPasswdFile $ olcPerlModule $ olcPerlModulePath $ olcPerlModuleConfig $ olcShellBind $ olcShellUnbind $ olcShellSearch $ olcShellCompare $ olcShellModify $ olcShellModRDN $ olcShellAdd $ olcShellDelete $ olcOvSocketOps $ olcOvSocketResps $ olcDbSocketPath $ olcDbSocketExtensions $ olcAccessLogOps $ olcAccessLogPurge $ olcAccessLogOld $ olcAccessLogOldAttr $ olcAccessLogBase $ olcAuditlogFile $ olcCollectInfo $ olcConstraintAttribute $ olcDDSmaxTtl $ olcDDSminTtl $ olcDDSdefaultTtl $ olcDDSinterval $ olcDDStolerance $ olcDGAttrPair $ olcDlAttrSet $ olcMemberOfDangling $ olcMemberOfGroupOC $ olcMemberOfMemberAD $ olcMemberOfMemberOfAD $ olcMemberOfDanglingError $ olcPcache $ olcPcacheAttrset $ olcPcacheTemplate $ olcPcachePosition $ olcPcacheBind $ olcRefintAttribute $ olcRetcodeItem $ olcRwmRewrite $ olcRwmTFSupport $ olcRwmMap $ olcSpCheckpoint $ olcTranslucentLocal $ olcTranslucentRemote $ olcUniqueIgnore $ olcUniqueAttribute $ olcUniqueURI $ olcValSortAttr $ knowledgeInformation $ sn $ serialNumber $ c $ l $ st $ street $ o $ ou $ title $ businessCategory $ postalCode $ postOfficeBox $ physicalDeliveryOfficeName $ destinationIndicator $ givenName $ initials $ generationQualifier $ dnQualifier $ houseIdentifier $ dmdName $ pseudonym $ textEncodedORAddress $ info $ drink $ roomNumber $ userClass $ host $ documentIdentifier $ documentTitle $ documentVersion $ documentLocation $ personalTitle $ co $ uniqueIdentifier $ organizationalStatus $ buildingName $ documentPublisher $ ipServiceProtocol $ nisMapName $ carLicense $ departmentNumber $ displayName $ employeeNumber $ employeeType $ preferredLanguage $ cmmac $ cmipadd $ servicelevel $ startdate $ enddate $ cmuid $ cmext1 $ cmext2 $ cmext3 $ cmext4 $ cmext5 $ cmext6 $ cmext7 $ cmext8 $ cmext9 ) ) 502475bc 1.2.36.79672281.1.13.3 (rdnMatch): 502475bc 2.5.13.1 (distinguishedNameMatch): 502475bc matchingRuleUse: ( 2.5.13.1 NAME 'distinguishedNameMatch' APPLIES ( creatorsName $ modifiersName $ subschemaSubentry $ entryDN $ namingContexts $ aliasedObjectName $ dynamicSubtrees $ distinguishedName $ seeAlso $ olcDefaultSearchBase $ olcRootDN $ olcSchemaDN $ olcSuffix $ olcUpdateDN $ olcDbACLAuthcDn $ olcDbIDAssertAuthcDn $ olcRelay $ olcAccessLogDB $ memberOf $ olcMemberOfDN $ pwdPolicySubentry $ olcPPolicyDefault $ olcRefintNothing $ olcRefintModifiersName $ olcRetcodeParent $ olcUniqueBase $ member $ owner $ roleOccupant $ manager $ documentAuthor $ secretary $ associatedName $ dITRedirect ) ) 502475bc 2.5.13.0 (objectIdentifierMatch): 502475bc matchingRuleUse: ( 2.5.13.0 NAME 'objectIdentifierMatch' APPLIES ( supportedControl $ supportedExtension $ supportedFeatures $ supportedApplicationContext ) ) 502475bc slapd startup: initiated. 502475bc backend_startup_one: starting "cn=config" 502475bc config_back_db_open 502475bc config_build_entry: "cn=config" 502475bc config_build_entry: "cn=schema" 502475bc >>> dnNormalize: <cn={0}core> 502475bc <<< dnNormalize: <cn={0}core> 502475bc config_build_entry: "cn={0}core" 502475bc >>> dnNormalize: <cn={1}cosine> 502475bc <<< dnNormalize: <cn={1}cosine> 502475bc config_build_entry: "cn={1}cosine" 502475bc >>> dnNormalize: <cn={2}nis> 502475bc <<< dnNormalize: <cn={2}nis> 502475bc config_build_entry: "cn={2}nis" 502475bc >>> dnNormalize: <cn={3}inetorgperson> 502475bc <<< dnNormalize: <cn={3}inetorgperson> 502475bc config_build_entry: "cn={3}inetorgperson" 502475bc >>> dnNormalize: <cn={4}cnrldap> 502475bc <<< dnNormalize: <cn={4}cnrldap> 502475bc config_build_entry: "cn={4}cnrldap" 502475bc config_build_entry: "olcDatabase={-1}frontend" 502475bc config_build_entry: "olcDatabase={0}config" 502475bc config_build_entry: "olcDatabase={1}ndb" 502475bc config_build_entry: "olcOverlay={0}accesslog" 502475bc config_build_entry: "olcDatabase={2}bdb" 502475bc backend_startup_one: starting "dc=bgctv,dc=net,dc=cn" 502475bc backend_startup_one: starting "cn=auditlog" 502475bc bdb_db_open: database "cn=auditlog": unclean shutdown detected; attempting recovery. 502475bc bdb_db_open: warning - no DB_CONFIG file found in directory /usr/local/openldap-2.4.32/var/openldap-data: (14). Expect poor performance for suffix "cn=auditlog". 502475bc bdb_db_open: database "cn=auditlog": dbenv_open(/usr/local/openldap-2.4.32/var/openldap-data). 502475bc bdb_monitor_db_open: monitoring disabled; configure monitor database to enable 502475bc slapd starting 502475bc bdb_dn2entry("cn=auditlog") 502475bc => bdb_dn2id("cn=auditlog") 502475bc <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) 502475bc >>> dnNormalize: <cn=admin,dc=bgctv,dc=net,dc=cn> 502475bc <<< dnNormalize: <cn=admin,dc=bgctv,dc=net,dc=cn> 502475bc >>> dnNormalize: <cn=admin,dc=bgctv,dc=net,dc=cn> 502475bc <<< dnNormalize: <cn=admin,dc=bgctv,dc=net,dc=cn> *** glibc detected *** slapd: free(): invalid pointer: 0x0000000001d68f28 *** ======= Backtrace: ========= /lib64/libc.so.6[0x3f8207230f] /lib64/libc.so.6(cfree+0x4b)[0x3f8207276b] slapd(ber_memfree_x+0x33)[0x67a01f] slapd(ber_bvarray_free_x+0x5a)[0x67aca0] slapd(ber_bvarray_free+0x1a)[0x67acd3] slapd(ndb_entry_get+0x1fa)[0x54d24e] slapd(overlay_entry_get_ov+0x201)[0x4d9286] slapd[0x4d9360] slapd(be_entry_get_rw+0x93)[0x45ddca] slapd[0x5d4687] slapd[0x63f2d5] /lib64/libpthread.so.0[0x3f82c0673d] /lib64/libc.so.6(clone+0x6d)[0x3f820d3d1d] ======= Memory map: ======== 00400000-0072a000 r-xp 00000000 fd:00 3962485 /usr/local/openldap-2.4.32/libexec/slapd 0092a000-0093d000 rw-p 0032a000 fd:00 3962485 /usr/local/openldap-2.4.32/libexec/slapd 0093d000-009fd000 rw-p 0093d000 00:00 0 01ae8000-01ead000 rw-p 01ae8000 00:00 0 [heap] 4052d000-4052e000 ---p 4052d000 00:00 0 4052e000-40f2e000 rw-p 4052e000 00:00 0 41197000-41198000 ---p 41197000 00:00 0 41198000-411b8000 rw-p 41198000 00:00 0 411b8000-411b9000 ---p 411b8000 00:00 0 411b9000-411d9000 rw-p 411b9000 00:00 0 411d9000-411da000 ---p 411d9000 00:00 0 411da000-411fa000 rw-p 411da000 00:00 0 411fa000-411fb000 ---p 411fa000 00:00 0 411fb000-4121b000 rw-p 411fb000 00:00 0 4121b000-4121c000 ---p 4121b000 00:00 0 4121c000-4123c000 rw-p 4121c000 00:00 0 416c0000-416c1000 ---p 416c0000 00:00 0 416c1000-41ec1000 rw-p 416c1000 00:00 0 3f81c00000-3f81c1c000 r-xp 00000000 fd:00 65784 /lib64/ld-2.5.so 3f81e1b000-3f81e1c000 r--p 0001b000 fd:00 65784 /lib64/ld-2.5.so 3f81e1c000-3f81e1d000 rw-p 0001c000 fd:00 65784 /lib64/ld-2.5.so 3f82000000-3f8214e000 r-xp 00000000 fd:00 65785 /lib64/libc-2.5.so 3f8214e000-3f8234d000 ---p 0014e000 fd:00 65785 /lib64/libc-2.5.so 3f8234d000-3f82351000 r--p 0014d000 fd:00 65785 /lib64/libc-2.5.so 3f82351000-3f82352000 rw-p 00151000 fd:00 65785 /lib64/libc-2.5.so 3f82352000-3f82357000 rw-p 3f82352000 00:00 0 3f82400000-3f82402000 r-xp 00000000 fd:00 65786 /lib64/libdl-2.5.so 3f82402000-3f82602000 ---p 00002000 fd:00 65786 /lib64/libdl-2.5.so 3f82602000-3f82603000 r--p 00002000 fd:00 65786 /lib64/libdl-2.5.so 3f82603000-3f82604000 rw-p 00003000 fd:00 65786 /lib64/libdl-2.5.so 3f82800000-3f82882000 r-xp 00000000 fd:00 65790 /lib64/libm-2.5.so 3f82882000-3f82a81000 ---p 00082000 fd:00 65790 /lib64/libm-2.5.so 3f82a81000-3f82a82000 r--p 00081000 fd:00 65790 /lib64/libm-2.5.so 3f82a82000-3f82a83000 rw-p 00082000 fd:00 65790 /lib64/libm-2.5.so 3f82c00000-3f82c16000 r-xp 00000000 fd:00 65792 /lib64/libpthread-2.5.so 3f82c16000-3f82e15000 ---p 00016000 fd:00 65792 /lib64/libpthread-2.5.so 3f82e15000-3f82e16000 r--p 00015000 fd:00 65792 /lib64/libpthread-2.5.so 3f82e16000-3f82e17000 rw-p 00016000 fd:00 65792 /lib64/libpthread-2.5.so 3f82e17000-3f82e1b000 rw-p 3f82e17000 00:00 0 3f83000000-3f83007000 r-xp 00000000 fd:00 65793 /lib64/librt-2.5.so 3f83007000-3f83207000 ---p 00007000 fd:00 65793 /lib64/librt-2.5.so 3f83207000-3f83208000 r--p 00007000 fd:00 65793 /lib64/librt-2.5.so 3f83208000-3f83209000 rw-p 00008000 fd:00 65793 /lib64/librt-2.5.so 3f83400000-3f83403000 r-xp 00000000 fd:00 65640 /lib64/libuuid.so.1.2 3f83403000-3f83603000 ---p 00003000 fd:00 65640 /lib64/libuuid.so.1.2 3f83603000-3f83604000 rw-p 00003000 fd:00 65640 /lib64/libuuid.so.1.2 3f83800000-3f83815000 r-xp 00000000 fd:00 65799 /lib64/libselinux.so.1 3f83815000-3f83a15000 ---p 00015000 fd:00 65799 /lib64/libselinux.so.1 3f83a15000-3f83a17000 rw-p 00015000 fd:00 65799 /lib64/libselinux.so.1 3f83a17000-3f83a18000 rw-p 3f83a17000 00:00 0 3f83c00000-3f83c3b000 r-xp 00000000 fd:00 65798 /lib64/libsepol.so.1 3f83c3b000-3f83e3b000 ---p 0003b000 fd:00 65798 /lib64/libsepol.so.1 3f83e3b000-3f83e3c000 rw-p 0003b000 fd:00 65798 /lib64/libsepol.so.1 3f83e3c000-3f83e46000 rw-p 3f83e3c000 00:00 0 3f84000000-3f8412b000 r-xp 00000000 fd:00 3274780 /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so 3f8412b000-3f8432b000 ---p 0012b000 fd:00 3274780 /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so 3f8432b000-3f84334000 rw-p 0012b000 fd:00 3274780 /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so 3f84334000-3f84336000 rw-p 3f84334000 00:00 0 3f84400000-3f84409000 r-xp 00000000 fd:00 65800 /lib64/libcrypt-2.5.so 3f84409000-3f84608000 ---p 00009000 fd:00 65800 /lib64/libcrypt-2.5.so 3f84608000-3f84609000 r--p 00008000 fd:00 65800 /lib64/libcrypt-2.5.so 3f84609000-3f8460a000 rw-p 00009000 fd:00 65800 /lib64/libcrypt-2.5.so 3f8460a000-3f84638000 rw-p 3f8460a000 00:00 0 3f85800000-3f85815000 r-xp 00000000 fd:00 65663 /lib64/libnsl-2.5.so 3f85815000-3f85a14000 ---p 00015000 fd:00 65663 /lib64/libnsl-2.5.so 3f85a14000-3f85a15000 r--p 00014000 fd:00 65663 /lib64/libnsl-2.5.so 3f85a15000-3f85a16000 rw-p 00015000 fd:00 65663 /lib64/libnsl-2.5.so 3f85a16000-3f85a18000 rw-p 3f85a16000 00:00 0 3f86800000-3f868e6000 r-xp 00000000 fd:00 3130355 /usr/lib64/libstdc++.so.6.0.8 3f868e6000-3f86ae5000 ---p 000e6000 fd:00 3130355 /usr/lib64/libstdc++.so.6.0.8 3f86ae5000-3f86aeb000 r--p 000e5000 fd:00 3130355 /usr/lib64/libstdc++.so.6.0.8 3f86aeb000-3f86aee000 rw-p 000eb000 fd:00 3130355 /usr/lib64/libstdc++.so.6.0.8 3f86aee000-3f86b00000 rw-p 3f86aee000 00:00 0 3f89000000-3f89011000 r-xp 00000000 fd:00 65802 /lib64/libresolv-2.5.so 3f89011000-3f89211000 ---p 00011000 fd:00 65802 /lib64/libresolv-2.5.so 3f89211000-3f89212000 r--p 00011000 fd:00 65802 /lib64/libresolv-2.5.so 3f89212000-3f89213000 rw-p 00012000 fd:00 65802 /lib64/libresolv-2.5.so 3f89213000-3f89215000 rw-p 3f89213000 00:00 0 3f89400000-3f89402000 r-xp 00000000 fd:00 65804 /lib64/libcom_err.so.2.1 3f89402000-3f89601000 ---p 00002000 fd:00 65804 /lib64/libcom_err.so.2.1 3f89601000-3f89602000 rw-p 00001000 fd:00 65804 /lib64/libcom_err.so.2.1 3f8b000000-3f8b12d000 r-xp 00000000 fd:00 65801 /lib64/libcrypto.so.0.9.8e 3f8b12d000-3f8b32c000 ---p 0012d000 fd:00 65801 /lib64/libcrypto.so.0.9.8e 3f8b32c000-3f8b34d000 rw-p 0012c000 fd:00 65801 /lib64/libcrypto.so.0.9.8e 3f8b34d000-3f8b351000 rw-p 3f8b34d000 00:00 0 3f8c400000-3f8c491000 r-xp 00000000 fd:00 3130374 /usr/lib64/libkrb5.so.3.3 3f8c491000-3f8c691000 ---p 00091000 fd:00 3130374 /usr/lib64/libkrb5.so.3.3 3f8c691000-3f8c695000 rw-p 00091000 fd:00 3130374 /usr/lib64/libkrb5.so.3.3 3f8c800000-3f8c824000 r-xp 00000000 fd:00 3130373 /usr/lib64/libk5crypto.so.3.1 3f8c824000-3f8ca23000 ---p 00024000 fd:00 3130373 /usr/lib64/libk5crypto.so.3.1 3f8ca23000-3f8ca25000 rw-p 00023000 fd:00 3130373 /usr/lib64/libk5crypto.so.3.1 3f8cc00000-3f8cc02000 r-xp 00000000 fd:00 65803 /lib64/libkeyutils-1.2.so 3f8cc02000-3f8ce01000 ---p 00002000 fd:00 65803 /lib64/libkeyutils-1.2.so 3f8ce01000-3f8ce02000 rw-p 00001000 fd:00 65803 /lib64/libkeyutils-1.2.so 3f8dc00000-3f8dc08000 r-xp 00000000 fd:00 3130372 /usr/lib64/libkrb5support.so.0.1 3f8dc08000-3f8de07000 ---p 00008000 fd:00 3130372 /usr/lib64/libkrb5support.so.0.1 3f8de07000-3f8de08000 rw-p 00007000 fd:00 3130372 /usr/lib64/libkrb5support.so.0.1 3f91200000-3f9122c000 r-xp 00000000 fd:00 3130375 /usr/lib64/libgssapi_krb5.so.2.2 3f9122c000-3f9142c000 ---p 0002c000 fd:00 3130375 /usr/lib64/libgssapi_krb5.so.2.2 3f9142c000-3f9142e000 rw-p 0002c000 fd:00 3130375 /usr/lib64/libgssapi_krb5.so.2.2 3f91e00000-3f91e46000 r-xp 00000000 fd:00 65531 /lib64/libssl.so.0.9.8e 3f91e46000-3f92046000 ---p 00046000 fd:00 65531 /lib64/libssl.so.0.9.8e 3f92046000-3f9204c000 rw-p 00046000 fd:00 65531 /lib64/libssl.so.0.9.8e 3f92200000-3f92202000 r-xp 00000000 fd:00 65810 /lib64/libutil-2.5.so 3f92202000-3f92401000 ---p 00002000 fd:00 65810 /lib64/libutil-2.5.so 3f92401000-3f92402000 r--p 00001000 fd:00 65810 /lib64/libutil-2.5.so 3f92402000-3f92403000 rw-p 00002000 fd:00 65810 /lib64/libutil-2.5.so 2aaaaaaab000-2aaaab3a0000 rw-p 2aaaaaaab000 00:00 0 2aaaab3a0000-2aaaab3a6000 rw-s 00000000 fd:00 3962498 /usr/local/openldap-2.4.32/var/openldap-data/__db.001 2aaaab3a6000-2aaaac478000 rw-s 00000000 fd:00 3962499 /usr/local/openldap-2.4.32/var/openldap-data/__db.002 2aaaac478000-2aaac047a000 rw-s 00000000 fd:00 3962500 /usr/local/openldap-2.4.32/var/openldap-data/__db.003 2aaac047a000-2aaac06ba000 rw-s 00000000 fd:00 3962501 /usr/local/openldap-2.4.32/var/openldap-data/__db.004 2aaac06ba000-2aaac077e000 rw-s 00000000 fd:00 3962502 /usr/local/openldap-2.4.32/var/openldap-data/__db.005 2aaac077e000-2aaac0786000 rw-s 00000000 fd:00 3962503 /usr/local/openldap-2.4.32/var/openldap-data/__db.006 2b53b42db000-2b53b42dc000 rw-p 2b53b42db000 00:00 0 2b53b42ed000-2b53b42ee000 rw-p 2b53b42ed000 00:00 0 2b53b42ee000-2b53b445a000 r-xp 00000000 fd:00 7370254 /usr/local/db-4.8.30/lib/libdb-4.8.so 2b53b445a000-2b53b465a000 ---p 0016c000 fd:00 7370254 /usr/local/db-4.8.30/lib/libdb-4.8.so 2b53b465a000-2b53b465f000 rw-p 0016c000 fd:00 7370254 /usr/local/db-4.8.30/lib/libdb-4.8.so 2b53b465f000-2b53b476f000 r-xp 00000000 fd:00 5827230 /usr/local/mysql-cluster-com-7.1.8-linux-x86_64-glibc23/lib/libmysqlclient_r.so.16.0.0 2b53b476f000-2b53b486e000 ---p 00110000 fd:00 5827230 /usr/local/mysql-cluster-com-7.1.8-linux-x86_64-glibc23/lib/libmysqlclient_r.so.16.0.0 2b53b486e000-2b53b498e000 rw-p 0010f000 fd:00 5827230 /usr/local/mysql-cluster-com-7.1.8-linux-x86_64-glibc23/lib/libmysqlclient_r.so.16.0.0 2b53b498e000-2b53b4991000 rw-p 2b53b498e000 00:00 0 2b53b4991000-2b53b4bf0000 r-xp 00000000 fd:00 5827221 /usr/local/mysql-cluster-com-7.1.8-linux-x86_64-glibc23/lib/libndbclient.so.4.0.0 2b53b4bf0000-2b53b4cef000 ---p 0025f000 fd:00 5827221 /usr/local/mysql-cluster-com-7.1.8-linux-x86_64-glibc23/lib/libndbclient.so.4.0.0 2b53b4cef000-2b53b4e23000 rw-p 0025e000 fd:00 5827221 /usr/local/mysql-cluster-com-7.1.8-linux-x86_64-glibc23/lib/libndbclient.so.4.0.0 2b53b4e23000-2b53b4e2d000 rw-p 2b53b4e23000 00:00 0 2b53b4e2d000-2b53b4e45000 r-xp 00000000 fd:00 3121387 /usr/lib64/libsasl2.so.2.0.22 2b53b4e45000-2b53b5045000 ---p 00018000 fd:00 3121387 /usr/lib64/libsasl2.so.2.0.22 2b53b5045000-2b53b5046000 rw-p 00018000 fd:00 3121387 /usr/lib64/libsasl2.so.2.0.22 2b53b5046000-2b53b5047000 rw-p 2b53b5046000 00:00 0 2b53b5047000-2b53b5054000 r-xp 00000000 fd:00 65791 /lib64/libgcc_s-4.1.2-20080825.so.1 2b53b5054000-2b53b5254000 ---p 0000d000 fd:00 65791 /lib64/libgcc_s-4.1.2-20080825.so.1 2b53b5254000-2b53b5255000 rw-p 0000d000 fd:00 65791 /lib64/libgcc_s-4.1.2-20080825.so.1 2b53b5255000-2b53b5257000 rw-p 2b53b5255000 00:00 0 2b53b5257000-2b53b526b000 r-xp 00000000 fd:00 3117678 /usr/lib64/libz.so.1.2.3 2b53b526b000-2b53b546a000 ---p 00014000 fd:00 3117678 /usr/lib64/libz.so.1.2.3 2b53b546a000-2b53b546b000 rw-p 00013000 fd:00 3117678 /usr/lib64/libz.so.1.2.3 2b53b546b000-2b53b5470000 rw-p 2b53b546b000 00:00 0 2b53b5470000-2b53b547a000 r-xp 00000000 fd:00 65499 /lib64/libnss_files-2.5.so 2b53b547a000-2b53b5679000 ---p 0000a000 fd:00 65499 /lib64/libnss_files-2.5.so 2b53b5679000-2b53b567a000 r--p 00009000 fd:00 65499 /lib64/libnss_files-2.5.so 2b53b567a000-2b53b567b000 rw-p 0000a000 fd:00 65499 /lib64/libnss_files-2.5.so 2b53b567b000-2b53b567f000 r-xp 00000000 fd:00 65497 /lib64/libnss_dns-2.5.so 2b53b567f000-2b53b587e000 ---p 00004000 fd:00 65497 /lib64/libnss_dns-2.5.so 2b53b587e000-2b53b587f000 r--p 00003000 fd:00 65497 /lib64/libnss_dns-2.5.so 2b53b587f000-2b5Aborted my slapd.conf: # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # allow bind_v2 include /usr/local/openldap/etc/openldap/schema/core.schema include /usr/local/openldap/etc/openldap/schema/cosine.schema include /usr/local/openldap/etc/openldap/schema/nis.schema include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema include /usr/local/openldap/etc/openldap/schema/cnrldap.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. pidfile /var/run/slapd.pid argsfile /var/run/slapd.args #loglevel stats sync #loglevel -1 #loglevel trace args conns BER stats stats2 #loglevel 1 idletimeout 120 sizelimit unlimited timelimit 1800 # Load dynamic backend modules: modulepath /usr/local/openldap-2.4.21/libexec/openldap moduleload back_bdb.la moduleload accesslog.la # moduleload back_hdb.la # moduleload back_ldap.la # 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 # 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! ####################################################################### # BDB database definitions ####################################################################### database ndb suffix "dc=bgctv,dc=net,dc=cn" rootdn "cn=admin,dc=bgctv,dc=net,dc=cn" rootpw ghwl directory /usr/local/openldap/var/openldap-data dbconnect 172.30.5.20:1186 dbhost 172.30.5.20 dbname bgctv dbuser bgctv dbpass ghwl_h0 dbconnections 1 overlay accesslog logdb "cn=auditlog" logops writes logold (objectclass=*) #dbconnect 172.30.5.20:1186 #dbhost 172.30.5.20 #dbname auditlog #dbuser bgctv #dbpass ghwl_h0 #dbconnections 1 access to attrs=userPassword,shadowLastChange by anonymous auth by self write by * none access to dn.sub="ou=cm,dc=bgctv,dc=net,dc=cn" by dn="userid=cmadmin,dc=bgctv,dc=net,dc=cn" write by anonymous auth by * none access to * by dn="userid=cmadmin,dc=bgctv,dc=net,dc=cn" read by * none database bdb suffix "cn=auditlog" index reqStart eq

1 0

(ITS#7350) aclparse.c acl_unparse() attrval empty DN
by daniel＠pluta.biz 09 Aug '12

09 Aug '12

Full_Name: Daniel Pluta Version: MASTER OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:470:9feb:ff03:4dbf:1141:9dad:2f88) It seems to me, that the following acl statement isn't correctly unparsed within aclparse.c: to dn.base="ou=persons,o=test" attrs=seeAlso val/distinguishedNameMatch="" by users read Starting slapd using loglevel 128 reports: Backend ACL: access to dn.base="ou=persons,o=test" attrs=seeAlso by users read I would have expected: Backend ACL: access to dn.base="ou=persons,o=test" attrs=seeAlso val/distinguishedNameMatch="" by users read As the empty DN is empty, the problem seems to be located in aclparse.c's acl_unparse()'s statement if ( !BER_BVISEMPTY( &a->acl_attrval ) ) or even in the parse_acl() flagless spliting into left and right.

1 0

Re: (ITS#7349) openldap not supporting CAMELLIA ciphers
by hyc＠symas.com 09 Aug '12

09 Aug '12

goodgoingswati(a)gmail.com wrote: > Full_Name: Swati > Version: 2.4.32 > OS: RHEL5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (115.113.153.34) > > > openldap is not supporting CAMELLIA based ciphers(both RSA and DSA based) > I have configured SSL LDAP(LDAPS) and on checking SSL connection with LDAPS > server with CAMELLIA based cipher leads to failure in handshake: OpenLDAP doesn't implement any ciphers at all; the ciphers are provided by whichever TLS implementation you're using. Closing this ITS. > > openssl s_client -connect localhost:636 -showcerts -cipher > DHE-DSS-CAMELLIA256-SHA -state -CAfile /path_to_cert -cert /path_to_client_cert > -key /path_to_client_key > CONNECTED(00000003) > SSL_connect:before/connect initialization > SSL_connect:SSLv2/v3 write client hello A > SSL3 alert read:fatal:handshake failure > SSL_connect:error in SSLv2/v3 read server hello A > 47726707455072:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert > handshake failure:s23_clnt.c:741: > --- > no peer certificate available > --- > No client certificate CA names sent > --- > SSL handshake has read 7 bytes and written 102 bytes > --- > New, (NONE), Cipher is (NONE) > Secure Renegotiation IS NOT supported > Compression: NONE > Expansion: NONE > > Handshake is failing with all camellia ciphers. > > -- -- 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#7349) openldap not supporting CAMELLIA ciphers
by goodgoingswati＠gmail.com 09 Aug '12

09 Aug '12

Full_Name: Swati Version: 2.4.32 OS: RHEL5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (115.113.153.34) openldap is not supporting CAMELLIA based ciphers(both RSA and DSA based) I have configured SSL LDAP(LDAPS) and on checking SSL connection with LDAPS server with CAMELLIA based cipher leads to failure in handshake: openssl s_client -connect localhost:636 -showcerts -cipher DHE-DSS-CAMELLIA256-SHA -state -CAfile /path_to_cert -cert /path_to_client_cert -key /path_to_client_key CONNECTED(00000003) SSL_connect:before/connect initialization SSL_connect:SSLv2/v3 write client hello A SSL3 alert read:fatal:handshake failure SSL_connect:error in SSLv2/v3 read server hello A 47726707455072:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:741: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 102 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE Handshake is failing with all camellia ciphers.

1 0

Re: (ITS#7347) Exclusive bit masks for: ACL_WADD, ACL_WDEL, and ACL_WRITE
by daniel＠pluta.biz 08 Aug '12

08 Aug '12

Applying the patch accessible here: ftp://ftp.openldap.org/incoming/Daniel-Pluta-120808.patch together with the acl set below obsoletes ITS#6900. In combination they enable the mode of operation we described in section VI, subsection G. of the previously linked paper. to dn.base="ou=groups,o=test" attrs=children by users write by * none to dn.one="ou=groups,o=test" attrs=owner by dnattr=owner write continue by dnattr=owner self-z by * none break to dn.one="ou=groups,o=test" attrs=entry,@groupOfNames by dnattr=owner write by * none The patch enables support to independently substract the privileges 'z' or 'a' from 'w', while 'a' or 'z' remain in the resulting bit mask. The other way around, adding 'a' or 'z' privs is also supported. Nevertheless, in the sense of the subject of this ITS the patch represents only a workaround. A clean solution (separating the 'a', 'z' and 'w' bitmasks) is of course preferable. LDIF test cases using ldapmodify command: ldapmodify -x -D "cn=000001,ou=persons,o=test" ... #create group entry (should fail) dn: cn=its7347-fail,ou=groups,o=test changetype: add cn: its7347 objectClass: top objectClass: groupOfNames member: cn=000001,ou=persons,o=test owner: cn=000002,ou=persons,o=test #create group entry (should succeed) dn: cn=its7347-success,ou=groups,o=test changetype: add cn: its7347 objectClass: top objectClass: groupOfNames member: cn=000001,ou=persons,o=test owner: cn=000001,ou=persons,o=test #add another owner (should succeed) dn: cn=its7347-success,ou=groups,o=test changetype: modify add: owner owner: cn=000002,ou=persons,o=test #delete the other owner (should succeed) dn: cn=its7347-success,ou=groups,o=test changetype: modify delete: owner owner: cn=000002,ou=persons,o=test #delete the entry (should succeed) dn: cn=its7347-success,ou=groups,o=test changetype: delete #restore the group (should succeed) dn: cn=its7347-success,ou=groups,o=test changetype: add cn: its7347 objectClass: top objectClass: groupOfNames member: cn=000001,ou=persons,o=test owner: cn=000001,ou=persons,o=test owner: cn=000002,ou=persons,o=test #delete the entry (should succeed) dn: cn=its7347-success,ou=groups,o=test changetype: delete #again restore the entry (should succeed) dn: cn=its7347-success,ou=groups,o=test changetype: add cn: its7347 objectClass: top objectClass: groupOfNames member: cn=000001,ou=persons,o=test owner: cn=000001,ou=persons,o=test owner: cn=000002,ou=persons,o=test #try to delete the owner (should fail) dn: cn=its7347-success,ou=groups,o=test changetype: modify delete: owner owner: cn=000001,ou=persons,o=test #delete the entry (should succeed) dn: cn=its7347-success,ou=groups,o=test changetype: delete

1 0

Re: (ITS#7348) enhancement: check_password contrib module
by Guillaume.Rousse＠inria.fr 07 Aug '12

07 Aug '12

Ceci est un message signC) cryptographiquement au format MIME. --------------ms000000000208070102090606 Content-Type: multipart/mixed; boundary="------------050908090805020607010105" This is a multi-part message in MIME format. --------------050908090805020607010105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Here is the patch. --=20 Guillaume Rousse INRIA, Direction des syst=E8mes d'information Domaine de Voluceau Rocquencourt - BP 105 78153 Le Chesnay Tel: 01 39 63 58 31 --------------050908090805020607010105 Content-Type: text/x-patch; name="0001-ITS-7348-new-check_password-contrib-module.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename*0="0001-ITS-7348-new-check_password-contrib-module.patch" =46rom fa2f6730171ab5755f56ca66715b723df726026d Mon Sep 17 00:00:00 2001 From: Guillaume Rousse <guillomovitch(a)gmail.com> Date: Tue, 7 Aug 2012 17:39:21 +0200 Subject: [PATCH] ITS #7348: new check_password contrib module Signed-off-by: Guillaume Rousse <Guillame.Rousse(a)inria.fr> --- contrib/slapd-modules/README | 3 + contrib/slapd-modules/check-password/Makefile | 52 +++ contrib/slapd-modules/check-password/README | 146 +++++++++ .../slapd-modules/check-password/check_password.c | 356 +++++++++++++++= ++++++ 4 files changed, 557 insertions(+) create mode 100644 contrib/slapd-modules/check-password/Makefile create mode 100644 contrib/slapd-modules/check-password/README create mode 100644 contrib/slapd-modules/check-password/check_password.c= diff --git a/contrib/slapd-modules/README b/contrib/slapd-modules/README index db74379..d8005ff 100644 --- a/contrib/slapd-modules/README +++ b/contrib/slapd-modules/README @@ -20,6 +20,9 @@ allop (overlay) autogroup (overlay) Automated updates of group memberships. =20 +check_password (plugin) + External password quality check module for ppolicy + cloak (overlay) Hide specific attributes unless explicitely requested =20 diff --git a/contrib/slapd-modules/check-password/Makefile b/contrib/slap= d-modules/check-password/Makefile new file mode 100644 index 0000000..42dd18f --- /dev/null +++ b/contrib/slapd-modules/check-password/Makefile @@ -0,0 +1,52 @@ + +LDAP_SRC =3D ../../.. +LDAP_BUILD =3D ../../.. +LDAP_INC =3D -I$(LDAP_BUILD)/include -I$(LDAP_SRC)/include -I$(LDAP_SRC)= /servers/slapd +LDAP_LIB =3D $(LDAP_BUILD)/libraries/libldap_r/libldap_r.la \ + $(LDAP_BUILD)/libraries/liblber/liblber.la + +CRACKLIB_PATH =3D /usr/share/cracklib/pw_dict +CRACKLIB_INC =3D=20 +CRACKLIB_LIB =3D -lcrack + +CONFIG_PATH =3D /etc/openldap/check_password.conf + +LIBTOOL =3D $(LDAP_BUILD)/libtool +CC =3D gcc +OPT =3D -g -O2 -Wall +DEFS =3D -DHAVE_CRACKLIB -DCRACKLIB_DICTPATH=3D"\"$(CRACKLIB_PATH)\"" \ + -DCONFIG_FILE=3D"\"$(CONFIG_PATH)\"" -DDEBUG +INCS =3D $(LDAP_INC) $(CRACKLIB_INC) +LIBS =3D $(LDAP_LIB) $(CRACKLIB_LIB) + +PROGRAMS =3D check_password.la +LTVER =3D 0:0:0 + +prefix=3D/usr/local +exec_prefix=3D$(prefix) +ldap_subdir=3D/openldap + +libdir=3D$(exec_prefix)/lib +libexecdir=3D$(exec_prefix)/libexec +moduledir =3D $(libexecdir)$(ldap_subdir) + +.SUFFIXES: .c .o .lo + +.c.lo: + $(LIBTOOL) --mode=3Dcompile $(CC) $(OPT) $(DEFS) $(INCS) -c $< + +all: $(PROGRAMS) + +check_password.la: check_password.lo + $(LIBTOOL) --mode=3Dlink $(CC) $(OPT) -version-info $(LTVER) \ + -rpath $(moduledir) -module -o $@ $? $(LIBS) + +clean: + rm -rf *.o *.lo *.la .libs + +install: $(PROGRAMS) + mkdir -p $(DESTDIR)$(moduledir) + for p in $(PROGRAMS) ; do \ + $(LIBTOOL) --mode=3Dinstall cp $$p $(DESTDIR)$(moduledir) ; \ + done + diff --git a/contrib/slapd-modules/check-password/README b/contrib/slapd-= modules/check-password/README new file mode 100644 index 0000000..10191c2 --- /dev/null +++ b/contrib/slapd-modules/check-password/README @@ -0,0 +1,146 @@ + +check_password.c - OpenLDAP pwdChecker library + +2007-06-06 Michael Steinmann <msl(a)calivia.com> +2008-01-30 Pierre-Yves Bonnetain <py.bonnetain(a)ba-cst.com> +2009 Clement Oudot <clem.oudot(a)gmail.com> - LTB-project +2009 Jerome HUET - LTB-project + +check_password.c is an OpenLDAP pwdPolicyChecker module used to check th= e +strength and quality of user-provided passwords. + +This module is used as an extension of the OpenLDAP password policy cont= rols, +see slapo-ppolicy(5) section pwdCheckModule. + +check_password.c will run a number of checks on the passwords to ensure = minimum +strength and quality requirements are met. Passwords that do not meet th= ese +requirements are rejected. + + +Password checks +--------------- + - passwords shorter than 6 characters are rejected if cracklib is used = (because + cracklib WILL reject them). + + - syntactic checks controls how many different character classes are us= ed + (lower, upper, digit and punctuation characters). The minimum number = of + classes is defined in a configuration file. You can set the minimum f= or each + class. + + - passwords are checked against cracklib if cracklib is enabled at comp= ile + time. It can be disabled in configuration file. + +INSTALLATION +------------ +Use the provided Makefile to build the module. + +Compilation constants : + +CONFIG_FILE : Path to the configuration file.=20 + Defaults to /etc/openldap/check_password.conf + +DEBUG : If defined, check_password will syslog() its actions. + +Build dependencies +cracklib header files (link with -lcrack). The Makefile does not look fo= r +cracklib; you may need to provide the paths manually. + +Install into the slapd server module path. Change the installation +path to match with the OpenLDAP module path in the Makefile. + +The module may be defined with slapd.conf parameter "modulepath". + +USAGE +----- +To use this module you need to add objectClass pwdPolicyChecker with an = +attribute 'pwdCheckModule: check_password.so' to a password policy entry= =2E + +The module depends on a working cracklib installation including wordlist= files. +If the wordlist files are not readable, the cracklib check will be skipp= ed +silently. + +Note: pwdPolicyChecker modules are loaded on *every* password change ope= ration. + +Configuration +------------- +The configuration file (/etc/openldap/check_password.conf by default) co= ntains +parameters for the module. If the file is not found, parameters are give= n their +default value. + +The syntax of the file is : + +parameter value + +with spaces being delimiters. Parameter names ARE case sensitive (this m= ay +change in the future). + +Current parameters : + +- useCracklib: integer. Default value: 1. Set it to 0 to disable crackl= ib verification. + It has no effect if cracklib is not included at compile time. + +- minPoints: integer. Default value: 3. Minimum number of quality point= s a new + password must have to be accepted. One quality point is awarded for e= ach character + class used in the password. + +- minUpper: integer. Defaut value: 0. Minimum upper characters expected.= + +- minLower: integer. Defaut value: 0. Minimum lower characters expected.= + +- minDigit: integer. Defaut value: 0. Minimum digit characters expected.= + +- minPunct: integer. Defaut value: 0. Minimum punctuation characters exp= ected. + +Logs +---- +If a user password is rejected by an OpenLDAP pwdChecker module, the use= r will +*not* get a detailed error message, this is by design. + +Typical user message from ldappasswd(5): + Result: Constraint violation (19) + Additional info: Password fails quality checking policy + +A more detailed message is written to the server log. + +Server log: + check_password_quality: module error: (check_password.so) + Password for dn=3D".." does not pass required number of strength check= s (2 of 3) + + +Caveats +------- +Runtime errors with this module (such as cracklib configuration problems= ) may +bring down the slapd process. + +Use at your own risk. + + +TODO +---- +* use proper malloc function, see ITS#4998 + + +HISTORY +------- +* 2009-10-30 Clement OUDOT - LTB-project + Version 1.1 + - Apply patch from Jerome HUET for minUpper/minLower/minDigit/minPunc= t + +* 2009-02-05 Clement Oudot <clem.oudot(a)gmail.com> - LINAGORA Group + Version 1.0.3 + - Add useCracklib parameter in config file (with help of Pascal Pejac)= + - Prefix log messages with "check_password: " + - Log what character type is found for quality checking + +* 2008-01-31 Pierre-Yves Bonnetain <py.bonnetain(a)ba-cst.com> + Version 1.0.2 + - Several bug fixes. + - Add external config file + +* 2007-06-06 Michael Steinmann <msl(a)calivia.com> + Version 1.0.1 + - add dn to error messages + +* 2007-06-02 Michael Steinmann <msl(a)calivia.com> + Version 1.0 + diff --git a/contrib/slapd-modules/check-password/check_password.c b/cont= rib/slapd-modules/check-password/check_password.c new file mode 100644 index 0000000..da427e7 --- /dev/null +++ b/contrib/slapd-modules/check-password/check_password.c @@ -0,0 +1,356 @@ +/* + * check_password.c for OpenLDAP + * + * See LICENSE, README and INSTALL files + */ + +#include <string.h> +#include <ctype.h> +#include <portable.h> +#include <slap.h> + +#ifdef HAVE_CRACKLIB +#include "crack.h" +#endif + +#if defined(DEBUG) +#include <syslog.h> +#endif + +#ifndef CRACKLIB_DICTPATH +#define CRACKLIB_DICTPATH "/usr/share/cracklib/pw_dict" +#endif + +#ifndef CONFIG_FILE +#define CONFIG_FILE "/etc/openldap/check_password.conf" +#endif + +#define DEFAULT_QUALITY 3 +#define DEFAULT_CRACKLIB 1 +#define MEMORY_MARGIN 50 +#define MEM_INIT_SZ 64 +#define FILENAME_MAXLEN 512 + +#define PASSWORD_TOO_SHORT_SZ \ + "Password for dn=3D\"%s\" is too short (%d/6)" +#define PASSWORD_QUALITY_SZ \ + "Password for dn=3D\"%s\" does not pass required number of strength che= cks (%d of %d)" +#define BAD_PASSWORD_SZ \ + "Bad password for dn=3D\"%s\" because %s" + +typedef int (*validator) (char*); +static int read_config_file (char *); +static validator valid_word (char *); +static int set_quality (char *); +static int set_cracklib (char *); + +int check_password (char *pPasswd, char **ppErrStr, Entry *pEntry); + +static int set_quality (char *value) +{ +#if defined(DEBUG) + syslog(LOG_NOTICE, "check_password: Setting quality to [%s]", value); +#endif + + /* No need to require more quality than we can check for. */ + if (!isdigit(*value) || (int) (value[0] - '0') > 4) return DEFAULT_QUAL= ITY; + return (int) (value[0] - '0'); + +} + +static int set_cracklib (char *value) +{ +#if defined(DEBUG) + syslog(LOG_NOTICE, "check_password: Setting cracklib usage to [%s]", va= lue); +#endif + + + return (int) (value[0] - '0'); + +} + +static int set_digit (char *value) +{ +#if defined(DEBUG) + syslog(LOG_NOTICE, "check_password: Setting parameter to [%s]", value);= +#endif + if (!isdigit(*value) || (int) (value[0] - '0') > 9) return 0; + return (int) (value[0] - '0'); +} + +static validator valid_word (char *word) +{ + struct { + char * parameter; + validator dealer; + } list[] =3D { { "minPoints", set_quality }, + { "useCracklib", set_cracklib }, + { "minUpper", set_digit }, + { "minLower", set_digit }, + { "minDigit", set_digit }, + { "minPunct", set_digit }, + { NULL, NULL } }; + int index =3D 0; + +#if defined(DEBUG) + syslog(LOG_NOTICE, "check_password: Validating parameter [%s]", word); +#endif + + while (list[index].parameter !=3D NULL) { + if (strlen(word) =3D=3D strlen(list[index].parameter) && + strcmp(list[index].parameter, word) =3D=3D 0) { +#if defined(DEBUG) + syslog(LOG_NOTICE, "check_password: Parameter accepted."); +#endif + return list[index].dealer; + } + index++; + } + +#if defined(DEBUG) + syslog(LOG_NOTICE, "check_password: Parameter rejected."); +#endif + + return NULL; +} + +static int read_config_file (char *keyWord) +{ + FILE * config; + char * line; + int returnValue =3D -1; + + if ((line =3D ber_memcalloc(260, sizeof(char))) =3D=3D NULL) { + return returnValue; + } + + if ( (config =3D fopen(CONFIG_FILE, "r")) =3D=3D NULL) { +#if defined(DEBUG) + syslog(LOG_ERR, "check_password: Opening file %s failed", CONFIG_FILE)= ; +#endif + + ber_memfree(line); + return returnValue; + } + + while (fgets(line, 256, config) !=3D NULL) { + char *start =3D line; + char *word, *value; + validator dealer; + +#if defined(DEBUG) + /* Debug traces to syslog. */ + syslog(LOG_NOTICE, "check_password: Got line |%s|", line); +#endif + + while (isspace(*start) && isascii(*start)) start++; + + if (! isascii(*start)) + continue; + + if ((word =3D strtok(start, " \t")) && (dealer =3D valid_word(word)) &= & (strcmp(keyWord,word)=3D=3D0)) { + if ((value =3D strtok(NULL, " \t")) =3D=3D NULL) + continue; + +#if defined(DEBUG) + syslog(LOG_NOTICE, "check_password: Word =3D %s, value =3D %s", word,= value); +#endif + + returnValue =3D (*dealer)(value); + } + } + + fclose(config); + ber_memfree(line); + return returnValue; +} + +static int realloc_error_message (char ** target, int curlen, int nextle= n) +{ + if (curlen < nextlen + MEMORY_MARGIN) { +#if defined(DEBUG) + syslog(LOG_WARNING, "check_password: Reallocating szErrStr from %d to = %d", + curlen, nextlen + MEMORY_MARGIN); +#endif + ber_memfree(*target); + curlen =3D nextlen + MEMORY_MARGIN; + *target =3D (char *) ber_memalloc(curlen); + } + + return curlen; +} + + int +check_password (char *pPasswd, char **ppErrStr, Entry *pEntry) +{ + + char *szErrStr =3D (char *) ber_memalloc(MEM_INIT_SZ); + int mem_len =3D MEM_INIT_SZ; + + int nLen; + int nLower =3D 0; + int nUpper =3D 0; + int nDigit =3D 0; + int nPunct =3D 0; + int minLower =3D 0; + int minUpper =3D 0; + int minDigit =3D 0; + int minPunct =3D 0; + int nQuality =3D 0; + int i; + + /* Set a sensible default to keep original behaviour. */ + int minQuality =3D DEFAULT_QUALITY; + int useCracklib =3D DEFAULT_CRACKLIB; + + /** bail out early as cracklib will reject passwords shorter + * than 6 characters + */ + + nLen =3D strlen (pPasswd); + if ( nLen < 6) { + mem_len =3D realloc_error_message(&szErrStr, mem_len, + strlen(PASSWORD_TOO_SHORT_SZ) + + strlen(pEntry->e_name.bv_val) + 1); + sprintf (szErrStr, PASSWORD_TOO_SHORT_SZ, pEntry->e_name.bv_val, nLen)= ; + goto fail; + } + + /* Read config file */ + minQuality =3D read_config_file("minPoints"); + + useCracklib =3D read_config_file("useCracklib"); + minUpper =3D read_config_file("minUpper"); + minLower =3D read_config_file("minLower"); + minDigit =3D read_config_file("minDigit"); + minPunct =3D read_config_file("minPunct"); + + /** The password must have at least minQuality strength points with one= + * point for the first occurrance of a lower, upper, digit and + * punctuation character + */ + + for ( i =3D 0; i < nLen; i++ ) { + + if ( nQuality >=3D minQuality ) break; + + if ( islower (pPasswd[i]) ) { + minLower--; + if ( !nLower && (minLower < 1)) { + nLower =3D 1; nQuality++; +#if defined(DEBUG) + syslog(LOG_NOTICE, "check_password: Found lower character - quality = raise %d", nQuality); +#endif + } + continue; + } + + if ( isupper (pPasswd[i]) ) { + minUpper--; + if ( !nUpper && (minUpper < 1)) { + nUpper =3D 1; nQuality++; +#if defined(DEBUG) + syslog(LOG_NOTICE, "check_password: Found upper character - quality = raise %d", nQuality); +#endif + } + continue; + } + + if ( isdigit (pPasswd[i]) ) { + minDigit--; + if ( !nDigit && (minDigit < 1)) { + nDigit =3D 1; nQuality++; +#if defined(DEBUG) + syslog(LOG_NOTICE, "check_password: Found digit character - quality = raise %d", nQuality); +#endif + } + continue; + } + + if ( ispunct (pPasswd[i]) ) { + minPunct--; + if ( !nPunct && (minPunct < 1)) { + nPunct =3D 1; nQuality++; +#if defined(DEBUG) + syslog(LOG_NOTICE, "check_password: Found punctuation character - qu= ality raise %d", nQuality); +#endif + } + continue; + } + } + + if ( nQuality < minQuality ) { + mem_len =3D realloc_error_message(&szErrStr, mem_len, + strlen(PASSWORD_QUALITY_SZ) + + strlen(pEntry->e_name.bv_val) + 2); + sprintf (szErrStr, PASSWORD_QUALITY_SZ, pEntry->e_name.bv_val, + nQuality, minQuality); + goto fail; + } + +#ifdef HAVE_CRACKLIB + + /** Check password with cracklib */ + + if ( useCracklib > 0 ) { + int j =3D 0; + FILE* fp; + char filename[FILENAME_MAXLEN]; + char const* ext[] =3D { "hwm", "pwd", "pwi" }; + int nErr =3D 0; + + /** + * Silently fail when cracklib wordlist is not found + */ + + for ( j =3D 0; j < 3; j++ ) { + + snprintf (filename, FILENAME_MAXLEN - 1, "%s.%s", \ + CRACKLIB_DICTPATH, ext[j]); + + if (( fp =3D fopen ( filename, "r")) =3D=3D NULL ) { + + nErr =3D 1; + break; + + } else { + + fclose (fp); + + } + } + + char *r; + if ( nErr =3D=3D 0) { + + r =3D (char *) FascistCheck (pPasswd, CRACKLIB_DICTPATH); + if ( r !=3D NULL ) { + mem_len =3D realloc_error_message(&szErrStr, mem_len, + strlen(BAD_PASSWORD_SZ) + + strlen(pEntry->e_name.bv_val) + + strlen(r)); + sprintf (szErrStr, BAD_PASSWORD_SZ, pEntry->e_name.bv_val, r); + goto fail; + } + } + } + + else { +#if defined(DEBUG) + syslog(LOG_NOTICE, "check_password: Cracklib verification disabled by = configuration"); +#endif + } + +#endif + + *ppErrStr =3D strdup (""); + ber_memfree(szErrStr); + return (LDAP_SUCCESS); + +fail: + *ppErrStr =3D strdup (szErrStr); + ber_memfree(szErrStr); + return (EXIT_FAILURE); + +} + --=20 1.7.11.4 --------------050908090805020607010105-- --------------ms000000000208070102090606 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Signature cryptographique S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN7jCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIElTCCA32gAwIBAgIQK7maWQuBMVtp KDwyDC57STANBgkqhkiG9w0BAQUFADA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwHhcNMTEwMTExMDAwMDAwWhcNMTQwMTEw MjM1OTU5WjBYMQswCQYDVQQGEwJGUjEOMAwGA1UEChMFSU5SSUExGTAXBgNVBAMTEEd1aWxs YXVtZSBST1VTU0UxHjAcBgkqhkiG9w0BCQIWD3JvdXNzZUBpbnJpYS5mcjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANT2GRniP4zFepDfXQ9qHZCqmyGFsnxP1sAK5gRwh2xm 7EJgNSAlRVkmYdkrohltfjGJWvzmlIc8lgbzPSddeHhlc3SI8ZV3b9gWlyq3asH4oPJ3KuKh d8s2JLoll4pYRo+EqH/kLr8Tz3xfDEHtXNXiZ4QM6kniyLyk2QKc8UUsxd8f8gbiUW8yP2rB 9MgwbKYHn+EudkGbn+krQGbrBQRK83phYVGNnRy13mlu8Mb+9mmNCJq8cL6vhhIsGB4VRvhb k3pcZc2zFm9QJFziYLpdqINoh3vmSVHEVN0Oa3KecuXjiaboonCzXnxvdgLWQYAJNglpP7TV H4PTw+xXLZsCAwEAAaOCAXYwggFyMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2am MB0GA1UdDgQWBBRPxfiKCFknW2HnMSChZnApNelBwjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsr BgEEAbIxAQICHTA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3Jn L1RFUkVOQVBlcnNvbmFsQ0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0 cDovL2NydC50Y3MudGVyZW5hLm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcw AYYaaHR0cDovL29jc3AudGNzLnRlcmVuYS5vcmcwJAYDVR0RBB0wG4EZR3VpbGxhdW1lLlJv dXNzZUBpbnJpYS5mcjANBgkqhkiG9w0BAQUFAAOCAQEAQi0EyaS/cO1avHkqFkOVhX5kuG3y kUlOIrzga2dnR2H7ylRILOTxBLweXL2DKJN+ZPJleLJSmdVcstq0GneSA7D1kJt0aPdMHqI6 8fMcppQer+N1V/9LYJWWRTV6RFrlSduzEU5tmdlG7QbYtvgNtvBliZL06AYPO54FDkHrhfnJ ldS55eeuAkwFrYkJP1Aa+zo/H2ytzVnIICtZMsZSa7Y2xo4j5Ykxd0HIsc48lmnkDnZ08+yf AOjJis2tc9eeBdcvQ/Pck+woIDeW9vnahCRcOOqCbmith0cqFvEm8cb1ajPIKmlUGBJi97Qh XJV8FZcuIK1Naelj/8MDbcd3ZzCCBMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJ KoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2Fs dCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMY aHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkwNTE4MDAwMDAwWhcNMjgxMjMxMjM1 OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEg UGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDIFdn1M2ojoZAN z7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/QJUU1+erLSvr72tPt RYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECGKD+/VgjiSumD ouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51WJFuTuyku Q+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSbA/B/ 9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYw DgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEE AbIxAQICHTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVRO LVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcB AQRjMGEwOAYIKwYBBQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGll bnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqG SIb3DQEBBQUAA4IBAQAGK6lTLxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+Z jKr+oBl2PpkDMvp1gziKu2uapQwTstQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR 1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+pAMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j 90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3QyxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1J ZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWherqQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9o MYIDBzCCAwMCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQD ExJURVJFTkEgUGVyc29uYWwgQ0ECECu5mlkLgTFbaSg8Mgwue0kwCQYFKw4DAhoFAKCCAY0w GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwODA3MTU1NzI1 WjAjBgkqhkiG9w0BCQQxFgQUQ1jLCcKguMOiIFP7wDC8SLbfFfYwXgYJKwYBBAGCNxAEMVEw TzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVy c29uYWwgQ0ECECu5mlkLgTFbaSg8Mgwue0kwYAYLKoZIhvcNAQkQAgsxUaBPMDsxCzAJBgNV BAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBDQQIQ K7maWQuBMVtpKDwyDC57STBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgB ZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO AwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIIBANISMWbCVg4clpyyoU7WyOoP ENBalFbEzAbA7iBn6edoAEV8jgj41VcGlNsevz8kQrb59GzkjOqMXsIwHTsGvjky738QcFPu uXyb8ZY+ExFOhgscUVlQ924+idn6xPMstKuM/cPKrknqdrRsS6igOTMVhKjI0s0MX2vsSA8/ FLd48o7B8XE5vWCXpJKExRgZvJdbzxrY3fSFugo3/jrCPz62mquY9u4U55nspkADfd6Ws86J tzVhlZzAM+CGmBvXETbPOJpP6HV2ORAXhxSX/x2Rn07Rm8kShMVUSeSpg2cH5MiyAXNFwfix kZDykKSrudGq7u+YrAC/Q6isV4ohEZMAAAAAAAA= --------------ms000000000208070102090606--

1 0

(ITS#7348) enhancement: check_password contrib module
by Guillaume.Rousse＠inria.fr 07 Aug '12

07 Aug '12

Full_Name: Guillaume Rousse Version: current git HEAD OS: URL: Submission from: (NULL) (128.93.30.10) The attached patch provides an external password checker module for ppolicy. It was originally created by Michael Steinmann <msl(a)calivia.com>, then maintained by Clement Oudot <clem.oudot(a)gmail.com> as part of the LTP project (http://ltb-project.org/wiki/documentation/openldap-ppolicy-check-password). Integrating it directly as an openldap official contrib module would help its usage, as it relies on private OpenLDAP APIs. See README file for detailed history and copyrights.

1 0

Re: (ITS#6900) dnattr acl statement: users can produce dangling entries
by daniel＠pluta.biz 07 Aug '12

07 Aug '12

This ITS can be closed. See ITS#7347 instead, currently located http://www.openldap.org/its/index.cgi/Incoming?id=7347;selectid=7347#follow…

1 0

Re: (ITS#7347) Exclusive bit masks for: ACL_WADD, ACL_WDEL, and ACL_WRITE
by daniel＠pluta.biz 07 Aug '12

07 Aug '12

I've uploaded a quick workaround to check the above acl, it can be downloaded from here: ftp://ftp.openldap.org/incoming/its7347.patch => Test result: It works for me. In the sense of the ITS title it's just a half-way workaround: It addresses only subtractive ACLs, additive ACLs are not addressed. A clean solution, separating the bitmasks is of course preferable. In my opinion ITS#6900 should be closed.

1 0

Re: (ITS#7347) Exclusive bit masks for: ACL_WADD, ACL_WDEL, and ACL_WRITE
by Kurt＠OpenLDAP.org 06 Aug '12

06 Aug '12

On Aug 6, 2012, at 1:55 PM, daniel(a)pluta.biz wrote: > Full_Name: Daniel Pluta > Version: MASTER > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:470:9feb:ff03:e455:e36f:5b06:b2f1) > > > The "Enhancement for dnattr=... ACL" we've described within the LDAPcon2011 > paper (http://www.daasi.de/ldapcon2011/downloads/plutahommelweinert-paper.pdf, > Chapter VI, Section G., pdf page 7, left column bottom) seems to be still very > useful in our opinion. > > We (Peter an me) have discussed the idea behind this enhancement together with > Howard during dinner the day before the LDAPCon2011 officially started. We > described the enhancement as some kind of > "dnattr-based-administrator-less-2-way-handshake-entry-responsibility(-owner)-transition". > > Until today ITS#6900 contains a prototypical patch (very dirty hack), to > demonstrate the described enhancement's mode of operation. > > The good news: > Probably this hack isn't needed anymore in the future and thus ITS#6900 could be > closed, but just in case ... > > The bad news: > ... another (hopefully) less intrusive and generally useful patch, that seems to > be implementable without introducing new keywords can be realized instead: > > In http://www.openldap.org/lists/openldap-technical/201208/msg00040.html Kurt > explained that the acl privilege levels "a" and "z" share one bit with the "w" > privilege's bit set. Thus currently neither "a" nor "z" can be independently > substracted from "w" in the way either "z" or "a" remains in the privilege set. > Subtracting "a" or "z" results in removing the complete "w" privilege (including > "a" and "z"). Looking back at the devel discussion about the introduction of a/z privs (April 2005), there seems to have been no consideration of subtractive access controls. That is, I think the we all just missed the a/z feature was not implemented in a manner which supported subtractive access controls. Or, more simply put, whoops. Using qualifiers was the mistake. Just should of replaced one bit with 2 bits, with some operations requesting one or the other or both bits. > In case the bit masks of the privileges "a", "z", and "w" can be separated > (introducing exclusive masks for ACL_WADD, ACL_WDEL and ACL_WRITE), the > following acl set offers the above described mode of operation (out-of-the-box > without the need to apply the hack submitted with ITS#6900): > > {0}to dn.base="ou=groups,o=iacm" attrs=children by users write by * none > {1}to dn.one="ou=groups,o=iacm" attrs=owner by dnattr=owner =dxcsraz continue > by dnattr=modifiersName -z by * none > {2}to dn.one="ou=groups,o=iacm" attrs=entry,@groupOfNames by dnattr=owner write > by * none > > I've not been able to test this acls yet (due to no available hack/patch). At > least in theory it should represent the mentioned enhancement's mode of > operation: > The owner attribute can be modified (add and delete) by any owner, but no owner > can remove himself from the owner attribute to either repudiate his personal > responsibility for an entry or to produce a dangling entry (an administrator > needs to clean up), in case it's the last owner. I'd have to think a bit harder whether the access controls above implement this properly, but I am sure {1} can be written using non-substractive ACLs. Off hand, probably requiring two to do it. > Herewith, the request for a more detailed description of a usecase where > substractive privileges are of general use should be answered. The general use case of additive and subtractive ACL is that it sometimes makes ACLs shorter. > Additionally I > also thought about the statement, that "good ACLs" are either static or > additive: I think I used the word "should", as in subtractive ACLs should be avoided. There are likely cases where their use can be well justified, just like default grant rules can sometimes be well justified. However, many security experts advise use of explicit grants (=) or additive (+) grants. I generally concur with this advice. > I have not been able to find a static or additive ACL solution to > implement the above described functionality in a similar elegant way (e.g. > without administratively maintained group patterns) > > Alternative 1: (elegant static/additive ACL) > There possibly exists a solution to express the above described mode of > operation already nowadays by using static and additive acls only, if so, I > appreciate any advice. > > Alternative 2: (coding the bitmask-separation) > I have no clue how(h)ard ;-) it is to implement (especially test) a successfull > separation of these bit masks. It was mentioned that the incremental processing > of privileges has been added later and the underlying design could be > suboptimal. Currently I don't know which pitfalls to be aware of (especially in > and around acl.c). Nevertheless and depending on the answer to alternative 1, > I'm interessted to give it a try, thus any thoughts and hints are very welcome, > too. The latter should be the preferred approach, IMO. The question I would have is wether an implementation of such would have any negative impact upon deployments. That's a real hard one to access, as deployments do some pretty crazy things. In short, it comes does to whether anyone does =w continue followed by -a or -z and expecting the outcome not to z or a respectively. -- Kurt > > Thanks a lot! >

1 0

(ITS#7347) Exclusive bit masks for: ACL_WADD, ACL_WDEL, and ACL_WRITE
by daniel＠pluta.biz 06 Aug '12

06 Aug '12

Full_Name: Daniel Pluta Version: MASTER OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:470:9feb:ff03:e455:e36f:5b06:b2f1) The "Enhancement for dnattr=... ACL" we've described within the LDAPcon2011 paper (http://www.daasi.de/ldapcon2011/downloads/plutahommelweinert-paper.pdf, Chapter VI, Section G., pdf page 7, left column bottom) seems to be still very useful in our opinion. We (Peter an me) have discussed the idea behind this enhancement together with Howard during dinner the day before the LDAPCon2011 officially started. We described the enhancement as some kind of "dnattr-based-administrator-less-2-way-handshake-entry-responsibility(-owner)-transition". Until today ITS#6900 contains a prototypical patch (very dirty hack), to demonstrate the described enhancement's mode of operation. The good news: Probably this hack isn't needed anymore in the future and thus ITS#6900 could be closed, but just in case ... The bad news: ... another (hopefully) less intrusive and generally useful patch, that seems to be implementable without introducing new keywords can be realized instead: In http://www.openldap.org/lists/openldap-technical/201208/msg00040.html Kurt explained that the acl privilege levels "a" and "z" share one bit with the "w" privilege's bit set. Thus currently neither "a" nor "z" can be independently substracted from "w" in the way either "z" or "a" remains in the privilege set. Subtracting "a" or "z" results in removing the complete "w" privilege (including "a" and "z"). In case the bit masks of the privileges "a", "z", and "w" can be separated (introducing exclusive masks for ACL_WADD, ACL_WDEL and ACL_WRITE), the following acl set offers the above described mode of operation (out-of-the-box without the need to apply the hack submitted with ITS#6900): {0}to dn.base="ou=groups,o=iacm" attrs=children by users write by * none {1}to dn.one="ou=groups,o=iacm" attrs=owner by dnattr=owner =dxcsraz continue by dnattr=modifiersName -z by * none {2}to dn.one="ou=groups,o=iacm" attrs=entry,@groupOfNames by dnattr=owner write by * none I've not been able to test this acls yet (due to no available hack/patch). At least in theory it should represent the mentioned enhancement's mode of operation: The owner attribute can be modified (add and delete) by any owner, but no owner can remove himself from the owner attribute to either repudiate his personal responsibility for an entry or to produce a dangling entry (an administrator needs to clean up), in case it's the last owner. Herewith, the request for a more detailed description of a usecase where substractive privileges are of general use should be answered. Additionally I also thought about the statement, that "good ACLs" are either static or additive: I have not been able to find a static or additive ACL solution to implement the above described functionality in a similar elegant way (e.g. without administratively maintained group patterns). Alternative 1: (elegant static/additive ACL) There possibly exists a solution to express the above described mode of operation already nowadays by using static and additive acls only, if so, I appreciate any advice. Alternative 2: (coding the bitmask-separation) I have no clue how(h)ard ;-) it is to implement (especially test) a successfull separation of these bit masks. It was mentioned that the incremental processing of privileges has been added later and the underlying design could be suboptimal. Currently I don't know which pitfalls to be aware of (especially in and around acl.c). Nevertheless and depending on the answer to alternative 1, I'm interessted to give it a try, thus any thoughts and hints are very welcome, too. Thanks a lot!

1 0

Re: (ITS#7346) ACL processing: additive privs (using control continue)
by hyc＠symas.com 05 Aug '12

05 Aug '12

daniel(a)pluta.biz wrote: > Full_Name: Daniel Pluta > Version: MASTER > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.167.55.212) > > > For further explainations please vistit this technical-posting: > > http://www.openldap.org/lists/openldap-technical/201208/msg00025.html > > Testbed containing slapd.conf, data, ldapsearch-queries and 128-logs are given > below. As noted in the referenced email thread, this is working as designed. "continue" controls are only useful when a following clause matches the same subject and specifies incremental privileges. There are no following clauses that match the subject in this case, so the implicit "by * none" at the end of every ACL clause is applied. 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#7346) ACL processing: additive privs (using control continue)
by daniel＠pluta.biz 04 Aug '12

04 Aug '12

Full_Name: Daniel Pluta Version: MASTER OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.167.55.212) For further explainations please vistit this technical-posting: http://www.openldap.org/lists/openldap-technical/201208/msg00025.html Testbed containing slapd.conf, data, ldapsearch-queries and 128-logs are given below. Thanks a lot ------8<--------- slapd.conf --------8<--------- include /opt/openldap-HEAD/etc/openldap/schema/core.schema pidfile /opt/openldap-HEAD/var/run/slapd.pid argsfile /opt/openldap-HEAD/var/run/slapd.args access to * by self write by users read by anonymous auth database mdb suffix "o=test" rootdn "cn=Manager,o=test" rootpw secret directory /opt/openldap-HEAD/var/openldap-data/test index objectClass eq access to dn.subtree="o=test" attrs=sn by users =s continue by group/groupOfNames/member="cn=readers,ou=groups,o=test" +r ------8<--------- sample data --------8<--------- version: 1 dn: o=test objectClass: organization objectClass: top o: test dn: ou=groups,o=test objectClass: organizationalUnit objectClass: top ou: groups dn: ou=persons,o=test objectClass: organizationalUnit objectClass: top ou: persons dn: cn=PersonA,ou=persons,o=test objectClass: person objectClass: top cn: PersonA sn: PersonA userPassword:: UGVyc29uQQ== dn: cn=PersonB,ou=persons,o=test objectClass: person objectClass: top cn: PersonB sn: PersonB userPassword:: UGVyc29uQg== dn: cn=readers,ou=groups,o=test objectClass: groupOfNames objectClass: top cn: readers member: cn=PersonA,ou=persons,o=test ------8<---------Tests using ldapsearch--------8<--------- #Test 1 seem to work as intended: # bindDn "cn=PersonA,..." is member of group "cn=readers,..." # filter: sn=* # search succeeds (that's ok) # read succeeds (that's ok, too) deepee@test:~$ ldapsearch -x -H "ldap://localhost:1389/"; -D "cn=PersonA,ou=persons,o=test" -w PersonA -b "ou=persons,o=test" '(sn=*)' sn cn # extended LDIF # # LDAPv3 # base <ou=persons,o=test> with scope subtree # filter: (sn=*) # requesting: sn cn # # PersonA, persons, test dn: cn=PersonA,ou=persons,o=test sn: PersonA cn: PersonA # PersonB, persons, test dn: cn=PersonB,ou=persons,o=test cn: PersonB sn: PersonB # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 #slapd's log (level 128): 501be157 => access_allowed: result not in cache (userPassword) 501be157 => access_allowed: auth access to "cn=PersonA,ou=persons,o=test" "userPassword" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [2] attr userPassword 501be157 => acl_mask: access to entry "cn=PersonA,ou=persons,o=test", attr "userPassword" requested 501be157 => acl_mask: to value by "", (=0) 501be157 <= check a_dn_pat: self 501be157 <= check a_dn_pat: users 501be157 <= check a_dn_pat: anonymous 501be157 <= acl_mask: [3] applying auth(=xd) (stop) 501be157 <= acl_mask: [3] mask: auth(=xd) 501be157 => slap_access_allowed: auth access granted by auth(=xd) 501be157 => access_allowed: auth access granted by auth(=xd) 501be157 => access_allowed: search access to "ou=persons,o=test" "entry" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [2] attr entry 501be157 => acl_mask: access to entry "ou=persons,o=test", attr "entry" requested 501be157 => acl_mask: to all values by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: self 501be157 <= check a_dn_pat: users 501be157 <= acl_mask: [2] applying read(=rscxd) (stop) 501be157 <= acl_mask: [2] mask: read(=rscxd) 501be157 => slap_access_allowed: search access granted by read(=rscxd) 501be157 => access_allowed: search access granted by read(=rscxd) 501be157 => access_allowed: search access to "ou=persons,o=test" "sn" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [1] attr sn 501be157 => acl_mask: access to entry "ou=persons,o=test", attr "sn" requested 501be157 => acl_mask: to all values by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: users 501be157 <= acl_mask: [1] applying =s (continue) 501be157 <= acl_mask: [1] mask: =s 501be157 <= check a_group_pat: cn=readers,ou=groups,o=test 501be157 => mdb_entry_get: found entry: "cn=readers,ou=groups,o=test" 501be157 <= acl_mask: [2] applying +r (stop) 501be157 <= acl_mask: [2] mask: =rs 501be157 => slap_access_allowed: search access granted by =rs 501be157 => access_allowed: search access granted by =rs 501be157 => access_allowed: search access to "cn=PersonA,ou=persons,o=test" "sn" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [1] attr sn 501be157 => acl_mask: access to entry "cn=PersonA,ou=persons,o=test", attr "sn" requested 501be157 => acl_mask: to all values by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: users 501be157 <= acl_mask: [1] applying =s (continue) 501be157 <= acl_mask: [1] mask: =s 501be157 <= check a_group_pat: cn=readers,ou=groups,o=test 501be157 <= acl_mask: [2] applying +r (stop) 501be157 <= acl_mask: [2] mask: =rs 501be157 => slap_access_allowed: search access granted by =rs 501be157 => access_allowed: search access granted by =rs 501be157 => access_allowed: read access to "cn=PersonA,ou=persons,o=test" "entry" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [2] attr entry 501be157 => acl_mask: access to entry "cn=PersonA,ou=persons,o=test", attr "entry" requested 501be157 => acl_mask: to all values by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: self 501be157 <= acl_mask: [1] applying write(=wrscxd) (stop) 501be157 <= acl_mask: [1] mask: write(=wrscxd) 501be157 => slap_access_allowed: read access granted by write(=wrscxd) 501be157 => access_allowed: read access granted by write(=wrscxd) 501be157 => access_allowed: result not in cache (sn) 501be157 => access_allowed: read access to "cn=PersonA,ou=persons,o=test" "sn" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [1] attr sn 501be157 => acl_mask: access to entry "cn=PersonA,ou=persons,o=test", attr "sn" requested 501be157 => acl_mask: to value by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: users 501be157 <= acl_mask: [1] applying =s (continue) 501be157 <= acl_mask: [1] mask: =s 501be157 <= check a_group_pat: cn=readers,ou=groups,o=test 501be157 <= acl_mask: [2] applying +r (stop) 501be157 <= acl_mask: [2] mask: =rs 501be157 => slap_access_allowed: read access granted by =rs 501be157 => access_allowed: read access granted by =rs 501be157 => access_allowed: result not in cache (cn) 501be157 => access_allowed: read access to "cn=PersonA,ou=persons,o=test" "cn" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [2] attr cn 501be157 => acl_mask: access to entry "cn=PersonA,ou=persons,o=test", attr "cn" requested 501be157 => acl_mask: to value by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: self 501be157 <= acl_mask: [1] applying write(=wrscxd) (stop) 501be157 <= acl_mask: [1] mask: write(=wrscxd) 501be157 => slap_access_allowed: read access granted by write(=wrscxd) 501be157 => access_allowed: read access granted by write(=wrscxd) 501be157 => access_allowed: search access to "cn=PersonB,ou=persons,o=test" "sn" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [1] attr sn 501be157 => acl_mask: access to entry "cn=PersonB,ou=persons,o=test", attr "sn" requested 501be157 => acl_mask: to all values by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: users 501be157 <= acl_mask: [1] applying =s (continue) 501be157 <= acl_mask: [1] mask: =s 501be157 <= check a_group_pat: cn=readers,ou=groups,o=test 501be157 <= acl_mask: [2] applying +r (stop) 501be157 <= acl_mask: [2] mask: =rs 501be157 => slap_access_allowed: search access granted by =rs 501be157 => access_allowed: search access granted by =rs 501be157 => access_allowed: read access to "cn=PersonB,ou=persons,o=test" "entry" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [2] attr entry 501be157 => acl_mask: access to entry "cn=PersonB,ou=persons,o=test", attr "entry" requested 501be157 => acl_mask: to all values by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: self 501be157 <= check a_dn_pat: users 501be157 <= acl_mask: [2] applying read(=rscxd) (stop) 501be157 <= acl_mask: [2] mask: read(=rscxd) 501be157 => slap_access_allowed: read access granted by read(=rscxd) 501be157 => access_allowed: read access granted by read(=rscxd) 501be157 => access_allowed: result not in cache (cn) 501be157 => access_allowed: read access to "cn=PersonB,ou=persons,o=test" "cn" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [2] attr cn 501be157 => acl_mask: access to entry "cn=PersonB,ou=persons,o=test", attr "cn" requested 501be157 => acl_mask: to value by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: self 501be157 <= check a_dn_pat: users 501be157 <= acl_mask: [2] applying read(=rscxd) (stop) 501be157 <= acl_mask: [2] mask: read(=rscxd) 501be157 => slap_access_allowed: read access granted by read(=rscxd) 501be157 => access_allowed: read access granted by read(=rscxd) 501be157 => access_allowed: result not in cache (sn) 501be157 => access_allowed: read access to "cn=PersonB,ou=persons,o=test" "sn" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [1] attr sn 501be157 => acl_mask: access to entry "cn=PersonB,ou=persons,o=test", attr "sn" requested 501be157 => acl_mask: to value by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: users 501be157 <= acl_mask: [1] applying =s (continue) 501be157 <= acl_mask: [1] mask: =s 501be157 <= check a_group_pat: cn=readers,ou=groups,o=test 501be157 <= acl_mask: [2] applying +r (stop) 501be157 <= acl_mask: [2] mask: =rs 501be157 => slap_access_allowed: read access granted by =rs 501be157 => access_allowed: read access granted by =rs #Test 2 does not seem to work as intended (at least to me): # bindDn "cn=PersonB,..." not a member of group "cn=readers,..." # filter: sn=* # read fails (that's ok) # search fails (but why is the privilege "=s" reset?) deepee@test:~$ ldapsearch -x -H "ldap://localhost:1389/"; -D "cn=PersonB,ou=persons,o=test" -w PersonB -b "ou=persons,o=test" '(sn=*)' sn cn # extended LDIF # # LDAPv3 # base <ou=persons,o=test> with scope subtree # filter: (sn=*) # requesting: sn cn # # search result search: 2 result: 0 Success # numResponses: 1 #slapd's log (level 128): 501be196 => access_allowed: result not in cache (userPassword) 501be196 => access_allowed: auth access to "cn=PersonB,ou=persons,o=test" "userPassword" requested 501be196 => dn: [1] o=test 501be196 => acl_get: [1] matched 501be196 => acl_get: [2] attr userPassword 501be196 => acl_mask: access to entry "cn=PersonB,ou=persons,o=test", attr "userPassword" requested 501be196 => acl_mask: to value by "", (=0) 501be196 <= check a_dn_pat: self 501be196 <= check a_dn_pat: users 501be196 <= check a_dn_pat: anonymous 501be196 <= acl_mask: [3] applying auth(=xd) (stop) 501be196 <= acl_mask: [3] mask: auth(=xd) 501be196 => slap_access_allowed: auth access granted by auth(=xd) 501be196 => access_allowed: auth access granted by auth(=xd) 501be196 => access_allowed: search access to "ou=persons,o=test" "entry" requested 501be196 => dn: [1] o=test 501be196 => acl_get: [1] matched 501be196 => acl_get: [2] attr entry 501be196 => acl_mask: access to entry "ou=persons,o=test", attr "entry" requested 501be196 => acl_mask: to all values by "cn=personb,ou=persons,o=test", (=0) 501be196 <= check a_dn_pat: self 501be196 <= check a_dn_pat: users 501be196 <= acl_mask: [2] applying read(=rscxd) (stop) 501be196 <= acl_mask: [2] mask: read(=rscxd) 501be196 => slap_access_allowed: search access granted by read(=rscxd) 501be196 => access_allowed: search access granted by read(=rscxd) 501be196 => access_allowed: search access to "ou=persons,o=test" "sn" requested 501be196 => dn: [1] o=test 501be196 => acl_get: [1] matched 501be196 => acl_get: [1] attr sn 501be196 => acl_mask: access to entry "ou=persons,o=test", attr "sn" requested 501be196 => acl_mask: to all values by "cn=personb,ou=persons,o=test", (=0) 501be196 <= check a_dn_pat: users 501be196 <= acl_mask: [1] applying =s (continue) 501be196 <= acl_mask: [1] mask: =s 501be196 <= check a_group_pat: cn=readers,ou=groups,o=test 501be196 => mdb_entry_get: found entry: "cn=readers,ou=groups,o=test" 501be196 <= acl_mask: no more <who> clauses, returning =0 (stop) 501be196 => slap_access_allowed: search access denied by =0 501be196 => access_allowed: no more rules 501be196 => access_allowed: search access to "cn=PersonA,ou=persons,o=test" "sn" requested 501be196 => dn: [1] o=test 501be196 => acl_get: [1] matched 501be196 => acl_get: [1] attr sn 501be196 => acl_mask: access to entry "cn=PersonA,ou=persons,o=test", attr "sn" requested 501be196 => acl_mask: to all values by "cn=personb,ou=persons,o=test", (=0) 501be196 <= check a_dn_pat: users 501be196 <= acl_mask: [1] applying =s (continue) 501be196 <= acl_mask: [1] mask: =s 501be196 <= check a_group_pat: cn=readers,ou=groups,o=test 501be196 <= acl_mask: no more <who> clauses, returning =0 (stop) 501be196 => slap_access_allowed: search access denied by =0 501be196 => access_allowed: no more rules 501be196 => access_allowed: search access to "cn=PersonB,ou=persons,o=test" "sn" requested 501be196 => dn: [1] o=test 501be196 => acl_get: [1] matched 501be196 => acl_get: [1] attr sn 501be196 => acl_mask: access to entry "cn=PersonB,ou=persons,o=test", attr "sn" requested 501be196 => acl_mask: to all values by "cn=personb,ou=persons,o=test", (=0) 501be196 <= check a_dn_pat: users 501be196 <= acl_mask: [1] applying =s (continue) 501be196 <= acl_mask: [1] mask: =s 501be196 <= check a_group_pat: cn=readers,ou=groups,o=test 501be196 <= acl_mask: no more <who> clauses, returning =0 (stop) 501be196 => slap_access_allowed: search access denied by =0 501be196 => access_allowed: no more rules

1 0

(ITS#7345) New Feature : Add Connection Information in Access Log Entries
by ldap＠htam.net 03 Aug '12

03 Aug '12

Full_Name: Mathieu MILLET Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/accesslog_addConnectionInformation.patch Submission from: (NULL) (82.67.21.31) Entries provided by the Access Log Overlay does not contain informations such as the IP Address of the client. This patch adds a simple attribute : reqConnInfo containing the content of o_conn->c_peer_name . Please review this patch because I'm not sure about what safety checks must be performed on these data before "merging" them. If this patch is accepted : I, Mathieu MILLET, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#7342) Password modify EXOP requires a DN
by hyc＠symas.com 02 Aug '12

02 Aug '12

Eric Clements wrote: > I filed it in response to a posting I saw on AFP548 regarding OS X. Some users have patched OpenLDAP to work around the issue. If you have a working patch that behaves as you think it should, you're welcome to submit it. Unfortunately, the RFC is explicitly silent on how other identity formats are represented. I.e., it doesn't even specify that SASL identities (such as used in SASL Bind) are valid here. > Though your statement is true, many SASL methods do not use DNs either. I > do not see why it is not allowed for passwordModify in the same way. If it behaves as designed then feel free to close. > > Thank you, > --------------------------- > Eric Clements > > On Aug 1, 2012, at 2:26 PM, Howard Chu <hyc(a)symas.com> wrote: > >> eclements(a)apple.com wrote: >>> Full_Name: Eric Clements >>> Version: 2.4.26 >>> OS: MacOS >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (17.193.15.131) >>> >>> >>> RFC 3062 Section 2.1 (authored by OpenLDAP) states that a password modify >>> request may or may not be an LDAP DN, yet OpenLDAP backend requires a DN. >> >> I'm not sure I understand why you've filed this ITS. The RFC doesn't specify >> that a server MUST support non-DN valued identities. It in fact says in Section 3: >> >> If the server does not recognize provided fields or does not support >> the combination of fields provided, it SHALL NOT change the user >> password. >> >> Clearly it is allowed for a server to reject identities if it doesn't >> recognize them. -- -- 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#7342) Password modify EXOP requires a DN
by eclements＠apple.com 02 Aug '12

02 Aug '12

I filed it in response to a posting I saw on AFP548 regarding OS X. Some users have patched OpenLDAP to work around the issue. Though your statement is true, many SASL methods do not use DNs either. I do not see why it is not allowed for passwordModify in the same way. If it behaves as designed then feel free to close. Thank you, --------------------------- Eric Clements On Aug 1, 2012, at 2:26 PM, Howard Chu <hyc(a)symas.com> wrote: > eclements(a)apple.com wrote: >> Full_Name: Eric Clements >> Version: 2.4.26 >> OS: MacOS >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (17.193.15.131) >> >> >> RFC 3062 Section 2.1 (authored by OpenLDAP) states that a password modify >> request may or may not be an LDAP DN, yet OpenLDAP backend requires a DN. > > I'm not sure I understand why you've filed this ITS. The RFC doesn't specify > that a server MUST support non-DN valued identities. It in fact says in Section 3: > > If the server does not recognize provided fields or does not support > the combination of fields provided, it SHALL NOT change the user > password. > > Clearly it is allowed for a server to reject identities if it doesn't > recognize them. > > -- > -- 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#7344) [PATCH] Add initial testsuit for slapo-constraint
by hyc＠symas.com 02 Aug '12

02 Aug '12

jsynacek(a)redhat.com wrote: > Full_Name: Jan Synacek > Version: master > OS: linux-fedora17 > URL: ftp://ftp.openldap.org/incoming/jsynacek-20120802-testsuit-slapo-constraint… > Submission from: (NULL) (209.132.186.34) > > > This patch adds an initial testsuit for slapo-constraint. Thanks, added to master. > > The attached file is derived from OpenLDAP Software. All of the modifications > to > OpenLDAP Software represented in the following patch(es) were developed by Red > Hat. Red Hat has not assigned rights and/or interest in this work to any party. > I, Jan Synacek am authorized by Red Hat, my employer, to release this work > under > the following terms. > > Red Hat hereby place the following modifications to OpenLDAP Software (and only > these modifications) into the public domain. Hence, these modifications may be > freely used and/or redistributed for any purpose with or without attribution > and/or other notice. > > -- -- 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#7344) [PATCH] Add initial testsuit for slapo-constraint
by jsynacek＠redhat.com 02 Aug '12

02 Aug '12

Full_Name: Jan Synacek Version: master OS: linux-fedora17 URL: ftp://ftp.openldap.org/incoming/jsynacek-20120802-testsuit-slapo-constraint… Submission from: (NULL) (209.132.186.34) This patch adds an initial testsuit for slapo-constraint. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Synacek am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#7342) Password modify EXOP requires a DN
by hyc＠symas.com 01 Aug '12

01 Aug '12

eclements(a)apple.com wrote: > Full_Name: Eric Clements > Version: 2.4.26 > OS: MacOS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (17.193.15.131) > > > RFC 3062 Section 2.1 (authored by OpenLDAP) states that a password modify > request may or may not be an LDAP DN, yet OpenLDAP backend requires a DN. I'm not sure I understand why you've filed this ITS. The RFC doesn't specify that a server MUST support non-DN valued identities. It in fact says in Section 3: If the server does not recognize provided fields or does not support the combination of fields provided, it SHALL NOT change the user password. Clearly it is allowed for a server to reject identities if it doesn't recognize them. -- -- 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#7343) dynlist overlay does not include attributes of an entry containing objectClass of the dynlist attrset
by openldap＠stormcloud9.net 01 Aug '12

01 Aug '12

Full_Name: Patrick Hemmer Version: 2.4.31 OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (98.211.220.204) The issue is that if the entry being dynamically added to the parent entry has the objectClass slapo-dynlist is configured to use (to determine expansion), that entry is not dynamically added to the parent. For example: ---- dn: olcOverlay={4}dynlist,olcDatabase={3}hdb,cn=config objectClass: olcDynamicList objectClass: olcOverlayConfig olcOverlay: {4}dynlist olcDlAttrSet: {0}labeledURIObject labeledURI ---- dn: cn=parent,dc=example,dc=com objectClass: groupOfNames objectClass: top objectClass: labeledURIObject cn: parent member: uid=foo,dc=example,dc=com labeledURI: ldap:///cn=child,dc=example,dc=com??base?(objectClass=*) dn: cn=child,dc=example,dc=com objectClass: groupOfNames objectClass: top objectClass: labeledURIObject member: uid=bar,dc=example,dc=com cn: child ---- In the above example, I would expect "member: uid=bar,dc=example,dc=com" to be added to cn=parent,dc=example,dc=com, but it isn't. Now the documentation clearly states recursion is not allowed, so if cn=child were to have a 'labeledURI', this labeledURI would not be expanded. But this is not what is being done here, cn=child has no labeledURI present. It also behaves perfectly fine if I pull the "objetClass: labeledURIObject" off cn=child. ldapsearch with objectClass labeledURIObject present on cn=child: ---- dn: cn=parent,dc=example,dc=com objectClass: groupOfNames objectClass: top objectClass: labeledURIObject cn: parent member: uid=foo,dc=example,dc=com labeledURI: ldap:///cn=child,dc=example,dc=com??base?(objectClass=*) ---- ldapsearch without objectClass labeledURIObject present on cn=child: ---- dn: cn=parent,dc=example,dc=com objectClass: groupOfNames objectClass: top objectClass: labeledURIObject cn: parent cn: child member: uid=foo,dc=example,dc=com member: uid=bar,dc=example,dc=com labeledURI: ldap:///cn=child,dc=example,dc=com??base?(objectClass=*) ----

1 0

(ITS#7342) Password modify EXOP requires a DN
by eclements＠apple.com 31 Jul '12

31 Jul '12

Full_Name: Eric Clements Version: 2.4.26 OS: MacOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (17.193.15.131) RFC 3062 Section 2.1 (authored by OpenLDAP) states that a password modify request may or may not be an LDAP DN, yet OpenLDAP backend requires a DN.

1 0

Re: (ITS#7340) Regression in slapo-constraint
by jsynacek＠redhat.com 31 Jul '12

31 Jul '12

On 07/30/2012 08:38 PM, Michael Ströder wrote: > Jan Synacek wrote: >> On 07/27/2012 10:47 PM, michael(a)stroeder.com wrote: >>> It seems there's a regression in slapo-constraint possibly caused by a patch for >>> ITS#7168. >> >> This works for me: >> >> slapd.ldif: >> ... >> dn: olcOverlay=constraint,olcDatabase={1}bdb,cn=config >> objectClass: olcOverlayConfig >> objectClass: olcConstraintConfig >> olcOverlay: constraint >> olcConstraintAttribute: mail count 3 >> olcConstraintAttribute: description count 2 >> ... > > From the excerpt above it seems you've only added a count constraint. > > Please use more features of slapo-constraint for testing, e.g. regex- or > URL-based constraints. > > The patch for ITS#7168 broke all my customer setups since I'm slapo-constraint > quite heavily. > > Ciao, Michael. > I'm having hard time reproducing this. Still works for me. Please provide a minimal setup and an example that fails, so I can fix the patch. Thank you. -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat

1 0

Re: (ITS#7340) Regression in slapo-constraint
by michael＠stroeder.com 30 Jul '12

30 Jul '12

This is a cryptographically signed message in MIME format. --------------ms010302040303070900010905 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jan Synacek wrote: > On 07/27/2012 10:47 PM, michael(a)stroeder.com wrote: >> It seems there's a regression in slapo-constraint possibly caused by a= patch for >> ITS#7168. >=20 > This works for me: >=20 > slapd.ldif: > ... > dn: olcOverlay=3Dconstraint,olcDatabase=3D{1}bdb,cn=3Dconfig > objectClass: olcOverlayConfig > objectClass: olcConstraintConfig > olcOverlay: constraint > olcConstraintAttribute: mail count 3 > olcConstraintAttribute: description count 2 > ... =46rom the excerpt above it seems you've only added a count constraint. Please use more features of slapo-constraint for testing, e.g. regex- or URL-based constraints. The patch for ITS#7168 broke all my customer setups since I'm slapo-const= raint quite heavily. Ciao, Michael. --------------ms010302040303070900010905 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwNzMwMTgzODQyWjAjBgkq hkiG9w0BCQQxFgQUbkqitqiUB3AUptpJBP8IZf85VpcwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEANow9ad7A3wr3HYgEMXZdssyB+upyWbuJ5LwbagTwOvHqIIJRTaKTIEvnUk09t4Jm5EIn Z0Nx7RX/HhOSbK94k1azYSpfabscyEubVv5tmmIJLJ6uwGIk9+9tMr7D0sXj8AKxc5qb96sc 1Aj3NidCu5dE/qJhdiMK84FTAjqMbouQ0v+DaTuw8BDIjcQL7XNxyu536WAOB/5BGOtfms8e SXH2bvNfYbw25+HdC8OTibBoMJrFXZExyT6lpqjgPcSrcixF1bK/Y9w8kxgqq7keFAw3rcuK 7vXpYMYKdazQFhr6Z4XlvH8AOeSdpDgyy9u3miaV/f5p1TBPyQyMAlq9SgAAAAAAAA== --------------ms010302040303070900010905--

1 0

Re: (ITS#7340) Regression in slapo-constraint
by jsynacek＠redhat.com 30 Jul '12

30 Jul '12

On 07/27/2012 10:47 PM, michael(a)stroeder.com wrote: > Full_Name: > Version: RE24 8a0ce24c5abaf687a41696d988f6a1330128368d > OS: > URL: > Submission from: (NULL) (79.227.171.183) > > > It seems there's a regression in slapo-constraint possibly caused by a patch for > ITS#7168. > > If the client sends valid data which not violates a constraint > CONSTRAINT_VIOLATION is returned: > > delete: departmentNumber > departmentNumber: old_number > - > add: departmentNumber > departmentNumber: new_number > - > > It seems turning off only the constraint for departmentNumber does not help. > Turning off all constraints makes it work. > This works for me: slapd.ldif: ... dn: olcOverlay=constraint,olcDatabase={1}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcConstraintConfig olcOverlay: constraint olcConstraintAttribute: mail count 3 olcConstraintAttribute: description count 2 ... root.ldif: dn: dc=my-domain,dc=com objectclass: dcObject objectclass: organization dc: my-domain o: My Domain corp. user.ldif: dn: cn=usr2,dc=my-domain,dc=com objectclass: inetOrgPerson objectclass: organizationalPerson cn: usr2 sn: usr2 mail: original(a)email.com description: desc1 description: desc2 test.ldif: dn: cn=usr2,dc=my-domain,dc=com changetype: modify delete: description description: desc1 - add: description description: desc1-mod < operation is successful > Am I misunderstanding something? If it still doesn't work for you, please, provide more information including your configuration and an example that fails. -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat

1 0

(ITS#7341) Ordered list error in overlays.sdf and "attr" in access-control.sdf
by ghenry＠OpenLDAP.org 30 Jul '12

30 Jul '12

Full_Name: Gavin Henry Version: master OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Small typos in access-control.sdf overlays.sdf.

1 0

Re: (ITS#7168) [PATCH] Fix count constraint when using multiple modifications
by quanah＠zimbra.com 27 Jul '12

27 Jul '12

--On Tuesday, June 19, 2012 5:19 AM +0000 jsynacek(a)redhat.com wrote: > On 06/07/2012 03:00 PM, Howard Chu wrote: >> jsynacek(a)redhat.com wrote: >>> Full_Name: Jan Synacek >>> Version: 2.4.29 >>> OS: Fedora 16 >>> URL: >>> http://jsynacek.fedorapeople.org/openldap/jsynacek-20120216-constraint- >>> count.patch Submission from: (NULL) (209.132.186.34) >>> This patch is broken. See ITS#7340 and discussion on -technical. --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

(ITS#7340) Regression in slapo-constraint
by michael＠stroeder.com 27 Jul '12

27 Jul '12

Full_Name: Version: RE24 8a0ce24c5abaf687a41696d988f6a1330128368d OS: URL: Submission from: (NULL) (79.227.171.183) It seems there's a regression in slapo-constraint possibly caused by a patch for ITS#7168. If the client sends valid data which not violates a constraint CONSTRAINT_VIOLATION is returned: delete: departmentNumber departmentNumber: old_number - add: departmentNumber departmentNumber: new_number - It seems turning off only the constraint for departmentNumber does not help. Turning off all constraints makes it work.

1 0

(ITS#7339) back-mdb aborts with online index additions
by hyc＠OpenLDAP.org 26 Jul '12

26 Jul '12

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.19.97.21) Submitted by: hyc Already fixed in d1a7fa267bdb9e27777ba87db44034ce83a75084 If new databases are added (such as when adding a new index via cn=config) they may cause additional pages to be dirtied during txn_commit. The pages would be pulled from the freelist. But the updates occurred after the freelist had already been written out, so the new state of the freelist wasn't being saved. Subsequent transactions would abort due to internal corruption.

1 0

(ITS#7338) Problems changing bdb DB_CONFIG parameters using back-config
by mhardin＠symas.com 26 Jul '12

26 Jul '12

Full_Name: Matthew Hardin Version: 2.4.31 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (69.43.206.100) Using back-config to update bdb DB_CONFIG parameters has problems. Changing the parameters with back-config does work, and writes out a new DB_CONFIG file, but a database reopen doesn't occur and therefore the environment is not rebuilt. Furthermore, if one restarts slapd, a checkpoint occurs, which in turn causes mtimes to change in the database and so the rebuild-env-on-dbopen step isn't triggered. The proper sequence should be: close the db write the new DB_CONFIG open the db The checkpoint will take place before DB_CONFIG is written, and on reopen, the environment will be rebuilt.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs