- openldap-bugs - openldap.org

(ITS#7682) LMDB: [PATCH] mdb_env_copy should retry open() if O_DIRECT fails
by sog＠msg.com.mx 06 Sep '13

06 Sep '13

Full_Name: Salvador Ortiz Version: 24 OS: Linux URL: ftp://ftp.msg.com.mx/pub/varios/0001-In-mdb_env_copy-retry-open-if-O_DIRECT-fails.patch Submission from: (NULL) (187.162.45.111) If the OS defines O_DIRECT mdb_env_copy unconditionally uses it, but according to open(2): "Some file systems may not implement the flag and open() will fail with EINVAL if it is used." In this cases mdb_env_copy should retry without the flag. The attached patch implements that.

1 0

Re: (ITS#7681) Bugfix for MDB_SET_RANGE
by hyc＠symas.com 05 Sep '13

05 Sep '13

claude.brisson(a)gmail.com wrote: > Full_Name: Claude Brisson > Version: HEAD > OS: linux 64 > URL: ftp://ftp.openldap.org/incoming/0001-fix-mdb_cursor_set-behaviour-for-MDB_S… > Submission from: (NULL) (84.103.74.195) > > > When no other page was found while provided key is less than found key, > mdb_cursor_get should not return MDB_NOTFOUND. > > The attached patch is a proposal to fix the behaviour of mdb_cursor_set for > MDB_SET_RANGE. Please review that it is correct before integration. Thanks. exactp is always NULL when using SET_RANGE, so that part of the patch is unnecessary. Otherwise looks OK. -- -- 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#7681) Bugfix for MDB_SET_RANGE
by claude.brisson＠gmail.com 05 Sep '13

05 Sep '13

Full_Name: Claude Brisson Version: HEAD OS: linux 64 URL: ftp://ftp.openldap.org/incoming/0001-fix-mdb_cursor_set-behaviour-for-MDB_S… Submission from: (NULL) (84.103.74.195) When no other page was found while provided key is less than found key, mdb_cursor_get should not return MDB_NOTFOUND. The attached patch is a proposal to fix the behaviour of mdb_cursor_set for MDB_SET_RANGE. Please review that it is correct before integration.

1 0

RE: (ITS#7673)
by Russell.Mosemann＠cune.edu 04 Sep '13

04 Sep '13

Pierangelo Masarati wrote: > Try rwm-drop-unrequested-attrs no (slapo-rwm(5)). That had my hopes up. I didn't think any of those settings applied, because nothing about the query or the results is being rewritten or mapped. In effect, rwm should not be doing anything at all. Everything should pass through the overlay. I set rwm-drop-unrequested-attrs to no, and it made things worse. If I include the filter attributes in the query, nothing is returned, now. If no attributes are specified, all of the allowed attributes are returned, as before. -- Russell Mosemann, Ph.D. Professor of Computer Science

1 0

Re: (ITS#7673)
by pierangelo.masarati＠polimi.it 04 Sep '13

04 Sep '13

On 09/04/2013 10:22 PM, Russell.Mosemann(a)cune.edu wrote: > --_000_B01302EA11DF7D40B2AD9CBEC71B02562C4A3ED5exchange2cunepr_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > The lookup succeeds, and the returned entry is run through the searchEntryD= > N context. It appears that somewhere in or around there all of the attribut= > es are removed except for the requested attributes. That means the ACL filt= > er will fail, if the filter attributes are not requested in the query. If t= > he requested attributes include the filter attributes, the query succeeds, = > but the result only returns the dn without any other attributes. > > If no attributes are requested, all allowed attributes are returned. > > The man page indicates that searchEntryDN should not be applied, because it= > is not defined, and there is no default. Try rwm-drop-unrequested-attrs no (slapo-rwm(5)). p. > > > --_000_B01302EA11DF7D40B2AD9CBEC71B02562C4A3ED5exchange2cunepr_ > Content-Type: text/html; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= > osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= > //www.w3.org/TR/REC-html40"> > <head> > <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= >> > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> > <style></style> > </head> > <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> > <div class=3D"WordSection1"> > mes New Roman","serif"">The lookup succeeds, and the returne= > d entry is run through the searchEntryDN context. It appears that somewhere= > in or around there all of the attributes are removed except > for the requested attributes. That means the ACL filter will fail, if the = > filter attributes are not requested in the query. If the requested attribut= > es include the filter attributes, the query succeeds, but the result only r= > eturns the dn without any other > attributes.<o:p></o:p> > mes New Roman","serif""><o:p> </o:p> > mes New Roman","serif"">If no attributes are requested, all = > allowed attributes are returned.<o:p></o:p> > mes New Roman","serif""><o:p> </o:p> > mes New Roman","serif"">The man page indicates that searchEn= > tryDN should not be applied, because it is not defined, and there is no def= > ault.<o:p></o:p> > mes New Roman","serif""><o:p> </o:p> > </div> > </body> > </html> > > --_000_B01302EA11DF7D40B2AD9CBEC71B02562C4A3ED5exchange2cunepr_-- > > > > > -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

(ITS#7673)
by Russell.Mosemann＠cune.edu 04 Sep '13

04 Sep '13

--_000_B01302EA11DF7D40B2AD9CBEC71B02562C4A3ED5exchange2cunepr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The lookup succeeds, and the returned entry is run through the searchEntryD= N context. It appears that somewhere in or around there all of the attribut= es are removed except for the requested attributes. That means the ACL filt= er will fail, if the filter attributes are not requested in the query. If t= he requested attributes include the filter attributes, the query succeeds, = but the result only returns the dn without any other attributes. If no attributes are requested, all allowed attributes are returned. The man page indicates that searchEntryDN should not be applied, because it= is not defined, and there is no default. --_000_B01302EA11DF7D40B2AD9CBEC71B02562C4A3ED5exchange2cunepr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> The lookup succeeds, and the returne= d entry is run through the searchEntryDN context. It appears that somewhere= in or around there all of the attributes are removed except for the requested attributes. That means the ACL filter will fail, if the = filter attributes are not requested in the query. If the requested attribut= es include the filter attributes, the query succeeds, but the result only r= eturns the dn without any other attributes.<o:p></o:p> <o:p> </o:p> If no attributes are requested, all = allowed attributes are returned.<o:p></o:p> <o:p> </o:p> The man page indicates that searchEn= tryDN should not be applied, because it is not defined, and there is no def= ault.<o:p></o:p> <o:p> </o:p> </div> </body> </html> --_000_B01302EA11DF7D40B2AD9CBEC71B02562C4A3ED5exchange2cunepr_--

1 0

Re: (ITS#7680) [Patch] Fix typos in manpages
by hyc＠symas.com 03 Sep '13

03 Sep '13

jsynacek(a)redhat.com wrote: > Full_Name: Jan Synacek > Version: master > OS: Linux - Fedora 19 > URL: http://jsynacek.fedorapeople.org/openldap/jsynacek-20130903-0001-Fix-typos-… > Submission from: (NULL) (209.132.186.34) > > > Minor documentation typos in ldapsearch.1 and slapd-passwd.5. > > Thanks, applied to master -- -- 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#7679) Problem with overlay dynlist
by pierangelo.masarati＠polimi.it 03 Sep '13

03 Sep '13

On 09/02/2013 04:52 PM, a.rossini(a)cineca.it wrote: > Full_Name: Angelo Rossini > Version: slapd 2.4.23 (Dec 16 2012 11:48:44) > OS: Debian GNU/Linux 6.0 2.6.32-5-amd64 x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (130.186.20.62) > > > I've tried to use the overlay dynlist to manage dynamic group; i've added these > rows to slapd.conf: > > # required schema for dynamic groups > include /etc/ldap/schema/dyngroup.schema > > # permanent load of the dynlist overlay > > moduleload dynlist > > overlay dynlist > dynlist-attrset groupOfURLs memberURL seeAlso > > And created a group using this LDIF: > > dn: cn=GROUP_DYN,ou=gruppi,o=unixx,dc=unixx,dc=it > > objectClass: groupOfURLs > > cn: GROUP_DYN > > memberURL: ldap:///ou=users,o=unixx,dc=unixx,dc=it??sub?(schacPersonalPosition=STUDENTE) > > When i try ldap searches like ldapsearch --baseDN > cn=GROUP_DYN,ou=gruppi,o=unixx,dc=unixx,dc=it '(objectClass=*)' or like > ldapsearch --baseDN cn=GROUP_DYN,ou=gruppi,o=unixx,dc=unixx,dc=it > 'isMemberOf=cn=GROUP_DYN,ou=gruppi,o=unixx,dc=unixx,dc=it' is not possible to > retrieve the list of distinguished names of the results but only a list of some > other attributes of the result. > > The configuration is exactly the one described in the > http://www.openldap.org/doc/admin24/overlays.html#Dynamic Lists page. > > What is wrong? So far, there is no evidence of a software bug. Does your build pass test044 ? If so, then it must be something in the way you're using the overlay. You should direct the discussion to the openldap-technical mailing list, and provide a simple, self-contained test case that reproduces the problem. p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

(ITS#7680) [Patch] Fix typos in manpages
by jsynacek＠redhat.com 03 Sep '13

03 Sep '13

Full_Name: Jan Synacek Version: master OS: Linux - Fedora 19 URL: http://jsynacek.fedorapeople.org/openldap/jsynacek-20130903-0001-Fix-typos-… Submission from: (NULL) (209.132.186.34) Minor documentation typos in ldapsearch.1 and slapd-passwd.5.

1 0

Re: Re : Re: (ITS#7676) OpenLDAP 2.4.36 slapd crash with "assertion failed" message
by hyc＠symas.com 03 Sep '13

03 Sep '13

"POISSON Frédéric" wrote: > Hello all, > > Thanks first for the patch, i have applied it on my own build of 2.4.36 but i > have now a strange behavior, the slapd do not crash but it refused operations. > > First here is the diff after applying the patch : > $ diff ../BUILD/openldap-2.4.36/servers/slapd/bconfig.c > ../BUILD/openldap-2.4.36/servers/slapd/bconfig.c.orig > 3795d3794 > < slap_tls_ctx = NULL; > 3804,3808d3802 > < } else { > < if ( rc == LDAP_NOT_SUPPORTED ) > < rc = LDAP_UNWILLING_TO_PERFORM; > < else > < rc = LDAP_OTHER; > > Now when i only add or replace only attribute olcTLSRandFile on cn=config i have : > > ldap_modify: Server is unwilling to perform (53) > > > When i replace following values in this order with 4 actions/operations or > with a single action/operation it works : > > dn: cn=config > changetype: modify > replace: olcTLSCACertificateFile > olcTLSCACertificateFile: /usr/products/openldap/etc/openldap-single/tls/cacert.pem > - > replace: olcTLSCertificateFile > olcTLSCertificateFile: /usr/products/openldap/etc/openldap-single/tls/cert.pem > - > replace: olcTLSCertificateKeyFile > olcTLSCertificateKeyFile: /usr/products/openldap/etc/openldap-single/tls/key.pem > - > replace: olcTLSRandFile > olcTLSRandFile: /dev/random > > But it don't works with only olcTLSRandfile if i do an add or replace first, why ? > > What do you need for investigation ? There's nothing to investigate, this works as designed. The config engine requires your TLS configuration to be valid when you configure it. That means at a minimum you must configure a server cert and key. If you only configure the randfile and nothing else, the config is rejected. -- -- 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#7673) rwm and bad ACL evaluation
by Russell.Mosemann＠cune.edu 02 Sep '13

02 Sep '13

> Hmm, maybe it's related to this: > http://www.openldap.org/its/index.cgi?findid=7495 extra_attrs is a great suggestion. Unfortunately, it doesn't work. If I execute the query and specify an attribute, it returns nothing. If I execute the query and do not specify an attribute, slapd dies, which is what you reported. -- Russell Mosemann, Ph.D. Professor of Computer Science

1 0

Re: (ITS#7678) Operational Error propagated from back-meta
by matth＠netsight.co.uk 02 Sep '13

02 Sep '13

On 2 Sep 2013, at 04:15 PM, Howard Chu <hyc(a)symas.com> wrote: > matth(a)netsight.co.uk wrote: >> Full_Name: Matt Hamilton >> Version: 2.4.36 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (213.133.64.253) >> >> >> I am using the meta backend to query multiple LDAP (AD) backends. This is to >> consolidate several directories in different departments into one. We attempt >> both simple binds with username/password and also anon binds to look up user >> information. > > That doesn't make much sense, since AD disallows anonymous Binds. Sorry, I wasn't clear. I mean we do both anon and simple binds to OpenLDAP. Hence why the config has credentials in it to use against the backends if not supplied by the client. >> At the moment, trying to do an authenticated simple bind to slapd caused an >> Operational Error to be propagated to the client regardless of the setting of >> 'onerr'. Even when a result is successfully found. This is due to one server in >> the backend succeeding and the other returning an operational error due to an >> invalid bind (as would be expected as the credentials supplied from the client >> will only work with one of the backends). >> >> Looking at servers/slapd/back-meta/search.c at around line 1903 it appears that >> the code is not checking for 'Operational Error' as a specific case above and so >> uses the default case (line 1665). Hence sres is set to 'Operational Error' too >> at line 1934. > > back-meta/search.c has nothing to do with Binds. Not sure what you're trying to demonstrate there. I'm not talking about binds there. I'm talking about errors being propagated. -Matt >> >> The server should be changing this to LDAP_SUCCESS somewhere in that logic >> unless META_BACK_ONERR_REPORT. > > -- > -- 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#7678) Operational Error propagated from back-meta
by hyc＠symas.com 02 Sep '13

02 Sep '13

matth(a)netsight.co.uk wrote: > Full_Name: Matt Hamilton > Version: 2.4.36 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.133.64.253) > > > I am using the meta backend to query multiple LDAP (AD) backends. This is to > consolidate several directories in different departments into one. We attempt > both simple binds with username/password and also anon binds to look up user > information. That doesn't make much sense, since AD disallows anonymous Binds. > At the moment, trying to do an authenticated simple bind to slapd caused an > Operational Error to be propagated to the client regardless of the setting of > 'onerr'. Even when a result is successfully found. This is due to one server in > the backend succeeding and the other returning an operational error due to an > invalid bind (as would be expected as the credentials supplied from the client > will only work with one of the backends). > > Looking at servers/slapd/back-meta/search.c at around line 1903 it appears that > the code is not checking for 'Operational Error' as a specific case above and so > uses the default case (line 1665). Hence sres is set to 'Operational Error' too > at line 1934. back-meta/search.c has nothing to do with Binds. Not sure what you're trying to demonstrate there. > > The server should be changing this to LDAP_SUCCESS somewhere in that logic > unless META_BACK_ONERR_REPORT. -- -- 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#7679) Problem with overlay dynlist
by a.rossini＠cineca.it 02 Sep '13

02 Sep '13

Full_Name: Angelo Rossini Version: slapd 2.4.23 (Dec 16 2012 11:48:44) OS: Debian GNU/Linux 6.0 2.6.32-5-amd64 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (130.186.20.62) I've tried to use the overlay dynlist to manage dynamic group; i've added these rows to slapd.conf: # required schema for dynamic groups include /etc/ldap/schema/dyngroup.schema # permanent load of the dynlist overlay moduleload dynlist overlay dynlist dynlist-attrset groupOfURLs memberURL seeAlso And created a group using this LDIF: dn: cn=GROUP_DYN,ou=gruppi,o=unixx,dc=unixx,dc=it objectClass: groupOfURLs cn: GROUP_DYN memberURL: ldap:///ou=users,o=unixx,dc=unixx,dc=it??sub?(schacPersonalPosition=STUDENTE) When i try ldap searches like ldapsearch --baseDN cn=GROUP_DYN,ou=gruppi,o=unixx,dc=unixx,dc=it '(objectClass=*)' or like ldapsearch --baseDN cn=GROUP_DYN,ou=gruppi,o=unixx,dc=unixx,dc=it 'isMemberOf=cn=GROUP_DYN,ou=gruppi,o=unixx,dc=unixx,dc=it' is not possible to retrieve the list of distinguished names of the results but only a list of some other attributes of the result. The configuration is exactly the one described in the http://www.openldap.org/doc/admin24/overlays.html#Dynamic Lists page. What is wrong? Regards, Angelo Rossini.

1 0

(ITS#7678) Operational Error propagated from back-meta
by matth＠netsight.co.uk 02 Sep '13

02 Sep '13

Full_Name: Matt Hamilton Version: 2.4.36 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.133.64.253) I am using the meta backend to query multiple LDAP (AD) backends. This is to consolidate several directories in different departments into one. We attempt both simple binds with username/password and also anon binds to look up user information. database meta suffix "DC=hscic,DC=nhs,DC=uk" rootdn "DC=hscic,DC=nhs,DC=uk" chase-referrals no norefs yes uri "ldap://dc1lv.npfit.nhs.uk/DC=hscic,DC=nhs,DC=uk" "ldap://dc2lv.npfit.nhs.uk" "ldap://dc1dr.npfit.nhs.uk" suffixmassage "DC=hscic,DC=nhs,DC=uk" "OU=Accounts - Active Users, OU=routine objects, DC=npfit, DC=nhs, DC=uk" idassert-bind bindmethod=simple binddn="CN=webuser,OU=Surnames Q to Z,OU=Accounts - Active Users,OU=Routine Objects,DC=npfit,DC=nhs,DC=uk" credentials="secret1" mode=self idassert-authzFrom "dn:*" uri "ldap://ts-l-dci-350.ic.green.net/DC=hscic,DC=nhs,DC=uk" "ldap://ts-l-dci-344.ic.green.net" "ldap://hg-l-dci-332.ic.green.net" suffixmassage "DC=hscic,DC=nhs,DC=uk" "OU=HSCIC,DC=ic,DC=Green,DC=Net" idassert-bind bindmethod=simple binddn="CN=z-CFHimport,OU=Service Accounts,OU=Administration,DC=ic,DC=Green,DC=Net" credentials="secret2" mode=self idassert-authzFrom "dn:*" At the moment, trying to do an authenticated simple bind to slapd caused an Operational Error to be propagated to the client regardless of the setting of 'onerr'. Even when a result is successfully found. This is due to one server in the backend succeeding and the other returning an operational error due to an invalid bind (as would be expected as the credentials supplied from the client will only work with one of the backends). Looking at servers/slapd/back-meta/search.c at around line 1903 it appears that the code is not checking for 'Operational Error' as a specific case above and so uses the default case (line 1665). Hence sres is set to 'Operational Error' too at line 1934. The server should be changing this to LDAP_SUCCESS somewhere in that logic unless META_BACK_ONERR_REPORT.

1 0

Re: (ITS#7673) rwm and bad ACL evaluation
by michael＠stroeder.com 02 Sep '13

02 Sep '13

This is a cryptographically signed message in MIME format. --------------ms030200060406090105050307 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Russell.Mosemann(a)cune.edu wrote: > Further testing confirms that the filter for the ACL is not being appli= ed > correctly when rwm is used. Turning the rewriteEngine off has no effect= =2E > All lines referring to rwm must be commented. >=20 > Interestingly, performing the query without specifying any attribute > succeeds. All allowed attributes are returned. Hmm, maybe it's related to this: http://www.openldap.org/its/index.cgi?findid=3D7495 Ciao, Michael. --------------ms030200060406090105050307 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwOTAyMTMzNzMyWjAj BgkqhkiG9w0BCQQxFgQUSUWFlNi+P3gVhEYcXVvCWpgF+p0wbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAHz5RR3K9GzJnvCkk+VEaz3FbSTprmvi/ Ey1b74sXSMNwTx85VZ12vvZZquUFwFxXckqtNoqlHQfggDf224UjQB0Fx8NTzdwKuMDJAjBI +/VGV0EP7EXkhHXoPjYAhiWU2QnX4/bWLMwIaXYhT2ANJL9dV03WU6Y2UoC6Sh+xdKEQOCA4 kjQ54Zi5e09/KuWl+3eIQivGzIi+5zbukV6VHvumpQd5IL4s1F8VTHpHgmMQiDLPK2xv5+Uc DuwnggSmLjskrUwg7uQtJARk3Cx6k9+SM0dB0c5Edrv8kDoDpFEanS5zvtRVP13/415dJJcP MH5Bv8s+9RzDAKF6D4vcAAAAAAAAAA== --------------ms030200060406090105050307--

1 0

RE: (ITS#7673) rwm and bad ACL evaluation
by Russell.Mosemann＠cune.edu 31 Aug '13

31 Aug '13

Further testing confirms that the filter for the ACL is not being applied correctly when rwm is used. Turning the rewriteEngine off has no effect. All lines referring to rwm must be commented. Interestingly, performing the query without specifying any attribute succeeds. All allowed attributes are returned. ldapsearch -D "qmailGID=306,ou=accounts,o=cune" -w password \ -E 2.16.840.1.113730.3.4.2 -b "ou=accounts,o=cune" "(uid=Test.Entry)" # extended LDIF # # LDAPv3 # base <ou=accounts,o=cune> with scope subtree # filter: (uid=Test.Entry) # requesting: ALL # # 2, accounts, cune dn: qmailUID=2,ou=accounts,o=cune objectClass: pilotPerson objectClass: qmailUser objectClass: PureFTPdUser cn: Test Entry sn: Entry uid: Test.Entry accountStatus: active mail: test.entry(a)cune.org userClass: stu # search result search: 2 result: 0 Success Specifying an allowed attribute or no attributes (1.1) causes the query to fail. For example, ldapsearch -D "qmailGID=306,ou=accounts,o=cune" -w password \ -E 2.16.840.1.113730.3.4.2 -b "ou=accounts,o=cune" "(uid=Test.Entry)" cn ldapsearch -D "qmailGID=306,ou=accounts,o=cune" -w password \ -E 2.16.840.1.113730.3.4.2 -b "ou=accounts,o=cune" "(uid=Test.Entry)" 1.1 # extended LDIF # # LDAPv3 # base <ou=accounts,o=cune> with scope subtree # filter: (uid=Test.Entry) # requesting: cn # # search result search: 2 result: 32 No such object # numResponses: 1 Removing the filter from the ACL allows the query to succeed. access to dn.subtree="ou=accounts,o=cune" attrs=cn,entry,mail,objectClass,sn,uid,userClass,accountStatus by dn="qmailGID=306,ou=accounts,o=cune" read by peername.ip=127.0.0.0%255.255.255.0 read by peername.ip=10.0.0.0%255.255.192.0 read by * none In summary, slapd is unable to apply the filter for an ACL correctly when rwm is being used and an attribute (or no attributes) is specified with the query.

1 0

Re: (ITS#7676) OpenLDAP 2.4.36 slapd crash with "assertion failed" message
by hyc＠symas.com 30 Aug '13

30 Aug '13

frederic.poisson(a)admin.gmessaging.net wrote: > Full_Name: Frederic POISSON > Version: 2.4.36 > OS: RHEL 6.2 > URL: ftp://ftp.openldap.org/incoming/slapcat_cn_config.ldif ftp://ftp.openldap.org/incoming/slapd_debug_255.txt ftp://ftp.openldap.org/incoming/gdb_output.txt > Submission from: (NULL) (57.250.229.136) Thanks for the report, this is now fixed in git master. > > I'm testing the latest release of OpenLDAP 2.4.36 and my slapd crash while i'm > doing a change on cn=config. > My tests are with my own compilation of OpenLDAP on a RHEL6 server but i see the > same problem with "LTB project RPMs" > http://ltb-project.org/wiki/download#openldap with RHEL6 package. > My aim is to modify cn=config like this in order to implement TLS, here is my > ldap modify command with ldif : > # /usr/local/openldap/bin/ldapmodify -f /tmp/ldif -h "localhost" -p "25389" -D > "cn=root DN,cn=config" -w "secret" > modifying entry "cn=config" > ldap_result: Can't contact LDAP server (-1) > > # cat /tmp/ldif > dn: cn=config > changetype: modify > add: olcTLSRandFile > olcTLSRandFile: /dev/random > > The server shutdown when i add this entry and with slapd option "-d 255" i have > : > slapd: result.c:813: slap_send_ldap_result: Assertion `!((rs->sr_err)<0)' > failed. > /etc/init.d/slapd: line 285: 5461 Aborted $SLAPD_BIN -h > "$SLAPD_SERVICES" $SLAPD_PARAMS > > Notice that i test this ldif modification on release 2.4.35 without problem. > > I put on your ftp three files, the file slapcat_cn_config.ldif corresponding to > configuration, the file slapd_debug_255.txt which correspond to the slapd > process with debug set to 255 with only the part corresponding to the moment i > launch ldapmodify action, the file gdb_output.txt corresponding to the full > backtrace i run when doing the ldapmodify action. > > And so the credentials are "cn=root DN,cn=config" with password secret. > > -- -- 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#7677) slapd crashes when modifying cn=config
by hyc＠symas.com 30 Aug '13

30 Aug '13

grimeton(a)gmx.net wrote: > Full_Name: Oliver Loch > Version: 2.4.36 > OS: Ubuntu 13.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.134.35.240) > > > Hi, > > when chaning TLS related configuration in cn=config, slapd crashes. > It looks pretty similar to ITS#7676. Yes, now fixed in master. Closing this as a dup of #7676. > > If you have questions, feel free to contact me. > > KR, > > Oliver > > -- -- 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#7677) slapd crashes when modifying cn=config
by grimeton＠gmx.net 30 Aug '13

30 Aug '13

Full_Name: Oliver Loch Version: 2.4.36 OS: Ubuntu 13.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.134.35.240) Hi, when chaning TLS related configuration in cn=config, slapd crashes. The slapd version 2.4.36 I'm using are packages that I built on my own with the help of the original Debian (!) source packages for 2.4.35. Even if the source packages come from Debian, they have been built on Ubuntu 13.04 and are used on Ubuntu 13.04. There are no "binary parts" of Debian involved in any way. If you want the source packages, just let me know. I kicked a lot of patches including the GNUTLS stuff and linked against OpenSSL. # ldd $(which slapd) linux-vdso.so.1 => (0x00007fffeddfe000) libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007f0a66da9000) liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007f0a66b9b000) libslp.so.1 => /usr/lib/libslp.so.1 (0x00007f0a66988000) libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f0a6676d000) libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f0a66534000) libslapi-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libslapi-2.4.so.2 (0x00007f0a66315000) libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7 (0x00007f0a6610b000) libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f0a65f01000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0a65ce3000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0a6591b000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f0a65701000) libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f0a654a3000) libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f0a650c8000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0a64ec4000) libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f0a64ca9000) /lib64/ld-linux-x86-64.so.2 (0x00007f0a6738c000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f0a64a92000) # I'm able to change any of the olcTLS* attributes in cn=config and only "olcTLSCACertificateFile" crashes slapd. When adding, the data is written to the cn=config backend and stored there (data available after a restart), when deleting, slapd crashes before the data has been written back. The LDIF file looks like this: ===== SNIP ===== 8< ======== dn: cn=config changetype: modify add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/certs/some.cert.pem - add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/private/cert.server.pem - add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/private/key.server.pem - add: olcTLSDHParamFile olcTLSDHParamFile: /etc/ssl/private/system.dhparam - add: olcTLSVerifyClient olcTLSVerifyClient: allow - add: olcTLSCRLCheck olcTLSCRLCheck: all - add: olcTLSCRLFile olcTLSCRLFile: /etc/ssl/certs/somecrl.crl.pem - ======= >8 ======= SNAP ======== The files do all exist and can be accessed by slapd. The error message before slapd core dumps: slapd: ../../../../servers/slapd/result.c:813: slap_send_ldap_result: Assertion `!((rs->sr_err)<0)' failed. Aborted (core dumped) It looks pretty similar to ITS#7676. If you have questions, feel free to contact me. KR, Oliver

1 0

(ITS#7676) OpenLDAP 2.4.36 slapd crash with "assertion failed" message
by frederic.poisson＠admin.gmessaging.net 30 Aug '13

30 Aug '13

Full_Name: Frederic POISSON Version: 2.4.36 OS: RHEL 6.2 URL: ftp://ftp.openldap.org/incoming/slapcat_cn_config.ldif ftp://ftp.openldap.org/incoming/slapd_debug_255.txt ftp://ftp.openldap.org/incoming/gdb_output.txt Submission from: (NULL) (57.250.229.136) I'm testing the latest release of OpenLDAP 2.4.36 and my slapd crash while i'm doing a change on cn=config. My tests are with my own compilation of OpenLDAP on a RHEL6 server but i see the same problem with "LTB project RPMs" http://ltb-project.org/wiki/download#openldap with RHEL6 package. My aim is to modify cn=config like this in order to implement TLS, here is my ldap modify command with ldif : # /usr/local/openldap/bin/ldapmodify -f /tmp/ldif -h "localhost" -p "25389" -D "cn=root DN,cn=config" -w "secret" modifying entry "cn=config" ldap_result: Can't contact LDAP server (-1) # cat /tmp/ldif dn: cn=config changetype: modify add: olcTLSRandFile olcTLSRandFile: /dev/random The server shutdown when i add this entry and with slapd option "-d 255" i have : slapd: result.c:813: slap_send_ldap_result: Assertion `!((rs->sr_err)<0)' failed. /etc/init.d/slapd: line 285: 5461 Aborted $SLAPD_BIN -h "$SLAPD_SERVICES" $SLAPD_PARAMS Notice that i test this ldif modification on release 2.4.35 without problem. I put on your ftp three files, the file slapcat_cn_config.ldif corresponding to configuration, the file slapd_debug_255.txt which correspond to the slapd process with debug set to 255 with only the part corresponding to the moment i launch ldapmodify action, the file gdb_output.txt corresponding to the full backtrace i run when doing the ldapmodify action. And so the credentials are "cn=root DN,cn=config" with password secret.

1 0

Re: (ITS#7675) Crash on mtestx.exe
by hyc＠symas.com 29 Aug '13

29 Aug '13

tghill(a)hotmail.com wrote: > Full_Name: TG Hill > Version: LMDB_0.9.7 > OS: Windows 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (216.211.58.121) > > > I frequently (but not always) get a crash when I run mtest(x).exe. It always > works after I delete data.mdb. It's normal. None of the test programs do any error checking, and they are not meant to be run. They are meant to be single-stepped under a debugger, and a developer is meant to examine the result of each call, manually. If you're not an LMDB developer you should just ignore these. Closing this ITS. > > The line causing the crash is listed below. > > rc = mdb_txn_begin(env, NULL, 0, &txn); > > > The binary was compiled using mingw gcc 4.6.2. > > I modified the makefile to use -lpthread or -mthreads so it would compile. Both > versions would periodically crash. > > Any ideas? > > Thanks! > > -- -- 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#7675) Crash on mtestx.exe
by tghill＠hotmail.com 29 Aug '13

29 Aug '13

Full_Name: TG Hill Version: LMDB_0.9.7 OS: Windows 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.211.58.121) I frequently (but not always) get a crash when I run mtest(x).exe. It always works after I delete data.mdb. The line causing the crash is listed below. rc = mdb_txn_begin(env, NULL, 0, &txn); The binary was compiled using mingw gcc 4.6.2. I modified the makefile to use -lpthread or -mthreads so it would compile. Both versions would periodically crash. Any ideas? Thanks!

1 0

Re: (ITS#7674) Configure Mirror Mode Replication
by quanah＠zimbra.com 28 Aug '13

28 Aug '13

--On Tuesday, August 27, 2013 11:19 PM +0000 cpetty(a)luthresearch.com wrote: > Full_Name: Clint Petty > Version: 2.4.23 > OS: CentOS 6.4 The ITS system is for bug reports. Help requests such as this should be sent to openldap-technical(a)openldap.org I would note the release you are using is ancient, and it is well known that the build from RedHat/CentOS has numerous problems and is quite broken. You would be best served to build a current release of OpenLDAP yourself, or grab the package from <http://ltb-project.org/wiki/download#openldap> for OpenLDAP 2.4.36. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7674) Configure Mirror Mode Replication
by cpetty＠luthresearch.com 28 Aug '13

28 Aug '13

Full_Name: Clint Petty Version: 2.4.23 OS: CentOS 6.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (65.44.192.153) I am wanting to implement Mirror Mode Replication. I am using OpenLDAP 2.4.23 which uses cn=config format, that does not have a slapd.conf file. The instructions say to add the following to the slapd.conf file: database bdb suffix dc=Example,dc=com rootdn dc=Example,dc=com directory /var/ldap/db index objectclass,entryCSN,entryUUID eq overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 MirrorMode node 1: # Global section serverID 1 # database section # syncrepl directive syncrepl rid=001 provider=ldap://ldap-sid2.example.com bindmethod=simple binddn="cn=mirrormode,dc=example,dc=com" credentials=mirrormode searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" mirrormode on MirrorMode node 2: # Global section serverID 2 # database section # syncrepl directive syncrepl rid=001 provider=ldap://ldap-sid1.example.com bindmethod=simple binddn="cn=mirrormode,dc=example,dc=com" credentials=mirrormode searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" mirrormode on Since there is no slapd.conf file, how do I configure replication in a cn=config format? Do I need to run a slapadd or ldapadd command? Syntax? What files do I need to create, and where? Thanks in advance.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs