openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

Re: (ITS#8213) When using the rwm, openldap down
by ryan＠nardis.ca 08 Aug '15

08 Aug '15

Hi, Patched in git master: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=7380… Please test the patch, and report any problems with it. Thanks!

1 0

(ITS#8213) When using the rwm, openldap down
by ohno＠designet.co.jp 08 Aug '15

08 Aug '15

Full_Name: Kimiyoshi Ohno Version: 2.4.41 OS: CentOS 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (220.211.13.215) When I changed configuration for openldap, openldap stopped. (Aborted) I was carried out the following operations. (1) I created the following environment. ---- ---- ---- ---- # ldapsearch -LLL -Y EXTERNAL -b 'olcOverlay={0}rwm,olcDatabase={1}bdb,cn=config' -H ldapi:/// SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: olcOverlay={0}rwm,olcDatabase={1}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: {0}rwm olcRwmRewrite: {0}rwm-rewriteEngine on olcRwmRewrite: {1}rwm-rewriteContext searchFilter olcRwmRewrite: {2}rwm-rewriteRule "aaa" "111" ":@" olcRwmRewrite: {3}rwm-rewriteRule "bbb" "222" ":@" ---- ---- ---- ---- (2) I created the following ldif file. ---- ---- ---- ---- dn: olcOverlay={0}rwm,olcDatabase={1}bdb,cn=config changetype: modify delete: olcRwmRewrite olcRwmRewrite: rwm-rewriteRule "aaa" "111" ":@" - ---- ---- ---- ---- (3) I was carried out ldapmodify. ---- ---- ---- ---- # ldapmodify -Y EXTERNAL -H ldapi:/// -f down.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "olcOverlay={0}rwm,olcDatabase={1}bdb,cn=config" ldap_result: Can't contact LDAP server (-1) ---- ---- ---- ---- In this case, openldap has stopped. : : 55c45c8b connection_get(16) 55c45c8b ==> sasl_bind: dn="" mech=EXTERNAL datalen=0 55c45c8b SASL Canonicalize [conn=1000]: authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" 55c45c8b slap_sasl_getdn: conn 1000 id=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth [len=55] 55c45c8b SASL Canonicalize [conn=1000]: slapAuthcDN="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" 55c45c8b SASL proxy authorize [conn=1000]: authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" authzid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" 55c45c8b connection_get(16) 55c45c8b conn=1000 op=1 do_modify: dn (olcOverlay={0}rwm,olcDatabase={1}bdb,cn=config) => ldap_bv2dn(olcOverlay={0}rwm,olcDatabase={1}bdb,cn=config,0) <= ldap_bv2dn(olcOverlay={0}rwm,olcDatabase={1}bdb,cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(clcOverlay={0}rwm,olcDatabase={1}bdb,cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(olcOverlay={0}rwm,olcDatabase={1}bdb,cn=config)=0 55c45c8b conn=1000 op=1 modifications: 55c45c8b delete: olcRwmRewrite 55c45c8b one value, length 32 55c45c8b [slapd:0] unknown command '' slapd: rwm.c:2195: rwm_cf_gen: Assertion `rc == 0' failed. Aborted Is this openldap BUG?

1 0

Re: (ITS#8054) Operation duration logging
by hyc＠symas.com 05 Aug '15

05 Aug '15

clem.oudot(a)gmail.com wrote: > 2015-02-11 18:33 GMT+01:00 <h.b.furuseth(a)usit.uio.no>: >> On 11. feb. 2015 12:38, Michael Str=C3=B6der wrote: >>> h.b.furuseth(a)usit.uio.no wrote: >>>> Cool feture, but please use fewer characteres in the already >>>> bloated log. How about "time=3D<integer>us" or even omit the "us"? >>> >>> +1 >>> >>> But 'time' sounds a bit general. >>> How about 'tdu' or even 'td' as abbreviation for "time duration"? >> >> I don't think so. You can't see from that what it means unless you >> already know, so you have to look it up just to see if you're >> interested. 'time' you can decide to look up if you are interested. >> > > Seems other LDAP servers have choosen 'etime' (see > http://ludopoitou.com/2015/02/24/about-auditing-ldap-operations/). Why > not try to use the same word? etime is fine with me. The other problem here is that it's counting duration from when slapd received the request (which is fine) but usually the op gets queued immediately after. For this etime to be useful we need to know both the amount of time spent queued, and the amount of time spent actually executing. qtime and etime? -- -- 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#8212) slapd stops on consumer node
by Steen.Brandtmar＠ibapplications.com 05 Aug '15

05 Aug '15

--_003_DB4PR03MB0911E60223F1AE5F6D332DA881750DB4PR03MB0911eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I did an upgrade to 2.4.41 on the consumer node. Then restarted. Consumer IP =3D 10.0.100.6 Provider IP=3D10.0.100.5 Then - on consumer - I executed this command: /usr/local/bin/ldappasswd -x -D uid=3Dxxxxxx,ou=3DPeople,dc=3Diba,dc=3Dloca= l -w oldpasswod -H ldap://10.0.100.6 -Z -s newpassword uid=3Dxxxxxx,ou=3DPe= ople,dc=3Diba,dc=3Dlocal ldap_result: Can't contact LDAP server (-1) And logfile writes: Aug 4 16:33:40 mgmt1 slapd[17418]: conn=3D1141 fd=3D18 ACCEPT from IP=3D10= .0.100.6:42621 (IP=3D0.0.0.0:389) Aug 4 16:33:40 mgmt1 slapd[17418]: conn=3D1141 op=3D0 EXT oid=3D1.3.6.1.4.= 1.1466.20037 Aug 4 16:33:40 mgmt1 slapd[17418]: conn=3D1141 op=3D0 STARTTLS Aug 4 16:33:40 mgmt1 slapd[17418]: conn=3D1141 op=3D0 RESULT oid=3D err=3D= 0 text=3D Aug 4 16:33:40 mgmt1 slapd[17418]: conn=3D1141 fd=3D18 TLS established tls= _ssf=3D128 ssf=3D128 Aug 4 16:33:40 mgmt1 slapd[17418]: conn=3D1141 op=3D1 BIND dn=3D"uid=3Dxxx= xxx,ou=3DPeople,dc=3Diba,dc=3Dlocal" method=3D128 Aug 4 16:33:40 mgmt1 slapd[17418]: conn=3D1141 op=3D1 BIND dn=3D"uid=3Dxxx= xxx,ou=3DPeople,dc=3Diba,dc=3Dlocal" mech=3DSIMPLE ssf=3D0 Aug 4 16:33:40 mgmt1 slapd[17418]: ppolicy_bind: Entry uid=3Dxxxxxx,ou=3DP= eople,dc=3Diba,dc=3Dlocal has an expired password: 6 grace logins Aug 4 16:33:41 mgmt1 slapd[17418]: conn=3D1141 op=3D1 RESULT tag=3D97 err= =3D0 text=3D Aug 4 16:33:41 mgmt1 slapd[17418]: conn=3D1141 op=3D2 EXT oid=3D1.3.6.1.4.= 1.4203.1.11.1 Aug 4 16:33:41 mgmt1 slapd[17418]: conn=3D1141 op=3D2 PASSMOD id=3D"uid=3D= xxxxxx,ou=3DPeople,dc=3Diba,dc=3Dlocal" new and slapd stops. I've attached configs for consumer and provider. Regards Steen Steen Brandtmar +45 2893 5392 Insurance Business Applications Gammel Kongevej 1, 4. sal 1610 K=F8benhavn, Danmark =A0=A0=A0 -----Original Message----- From: openldap-its(a)OpenLDAP.org [mailto:openldap-its@OpenLDAP.org]=20 Sent: 4. august 2015 13:55 To: Steen Brandtmar <Steen.Brandtmar(a)ibapplications.com> Subject: Re: (ITS#8212) slapd stops on consumer node *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report = has been assigned the tracking number ITS#8212. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunte= ers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue repo= rt, you may do so by replying to this message. Note that any mail sent to = openldap-its(a)openldap.org with (ITS#8212) in the subject will automatically= be attached to the issue report. mailto:openldap-its@openldap.org?subject=3D(ITS#8212) You may follow the progress of this report by loading the following URL in = a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=3D8212 Please remember to retain your issue tracking number (ITS#8212) on any furt= her messages you send to us regarding this report. If you don't then you'l= l just waste our time and yours because we won't be able to properly track = the report. Please note that the Issue Tracking System is not intended to be used to se= ek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. --_003_DB4PR03MB0911E60223F1AE5F6D332DA881750DB4PR03MB0911eurp_ Content-Type: text/plain; name="slapd.provider.conf.txt" Content-Description: slapd.provider.conf.txt Content-Disposition: attachment; filename="slapd.provider.conf.txt"; size=4671; creation-date="Tue, 04 Aug 2015 14:52:51 GMT"; modification-date="Tue, 04 Aug 2015 14:52:51 GMT" Content-Transfer-Encoding: base64 Iw0KIyBTZWUgc2xhcGQuY29uZig1KSBmb3IgZGV0YWlscyBvbiBjb25maWd1cmF0aW9uIG9wdGlv bnMuDQojIFRoaXMgZmlsZSBzaG91bGQgTk9UIGJlIHdvcmxkIHJlYWRhYmxlLg0KIw0KaW5jbHVk ZSAgICAgICAgIC91c3IvbG9jYWwvZXRjL29wZW5sZGFwL3NjaGVtYS9jb3JlLnNjaGVtYQ0KaW5j bHVkZSAgICAgICAgIC91c3IvbG9jYWwvZXRjL29wZW5sZGFwL3NjaGVtYS9jb3NpbmUuc2NoZW1h DQppbmNsdWRlICAgICAgICAgL3Vzci9sb2NhbC9ldGMvb3BlbmxkYXAvc2NoZW1hL25pcy5zY2hl bWENCmluY2x1ZGUgICAgICAgICAvdXNyL2xvY2FsL2V0Yy9vcGVubGRhcC9zY2hlbWEvaW5ldG9y Z3BlcnNvbi5zY2hlbWENCmluY2x1ZGUgICAgICAgICAvdXNyL2xvY2FsL2V0Yy9vcGVubGRhcC9z Y2hlbWEvc2FtYmEuc2NoZW1hDQppbmNsdWRlICAgICAgICAgL3Vzci9sb2NhbC9ldGMvb3Blbmxk YXAvc2NoZW1hL3Bwb2xpY3kuc2NoZW1hDQppbmNsdWRlICAgICAgICAgL3Vzci9sb2NhbC9ldGMv b3BlbmxkYXAvc2NoZW1hL2liYS5zY2hlbWENCmluY2x1ZGUgICAgICAgICAvdXNyL2xvY2FsL2V0 Yy9vcGVubGRhcC9zY2hlbWEvcmFkaXVzLnNjaGVtYQ0KIw0KIyBEZWZpbmUgZ2xvYmFsIEFDTHMg dG8gZGlzYWJsZSBkZWZhdWx0IHJlYWQgYWNjZXNzLg0KIw0KIyBEbyBub3QgZW5hYmxlIHJlZmVy cmFscyB1bnRpbCBBRlRFUiB5b3UgaGF2ZSBhIHdvcmtpbmcgZGlyZWN0b3J5DQojIHNlcnZpY2Ug QU5EIGFuIHVuZGVyc3RhbmRpbmcgb2YgcmVmZXJyYWxzLg0KI3JlZmVycmFsICAgICAgIGxkYXA6 Ly9yb290Lm9wZW5sZGFwLm9yZw0KIw0KcGlkZmlsZSAgL3Vzci9sb2NhbC92YXIvcnVuL3NsYXBk LnBpZA0KYXJnc2ZpbGUgL3Vzci9sb2NhbC92YXIvcnVuL3NsYXBkLmFyZ3MNCmxvZ2xldmVsIDI1 Ng0KIw0KIyBMb2FkIGR5bmFtaWMgYmFja2VuZCBtb2R1bGVzOg0KIyAgICAgICBjaGVja19wYXNz d29yZCBpcyBJQkFzIHNwZWNpYWwgcGFzc3dvcmQgY29tcGxpYW5jZSBtb2R1bGUNCiMgICAgICAg c21iazVwd2QgaXMgYSBtb2R1bGUgdGhhdCB1cGRhdGVzIHNhbWJhcHdkcyB3aGVuIHVzZXJwd2Rz IGNoYW5nZQ0KbW9kdWxlcGF0aCAgICAgIC91c3IvbG9jYWwvZXRjL29wZW5sZGFwL2liYQ0KbW9k dWxlbG9hZCAgICAgIGNoZWNrX3Bhc3N3b3JkLnNvDQptb2R1bGVsb2FkICAgICAgc21iazVwd2Qu c28NCiMgbW9kdWxlbG9hZCAgICBiYWNrX2JkYi5sYQ0KIyBtb2R1bGVsb2FkICAgIGJhY2tfaGRi LmxhDQojIG1vZHVsZWxvYWQgICAgYmFja19sZGFwLmxhDQojDQojIFNhbXBsZSBzZWN1cml0eSBy ZXN0cmljdGlvbnMNCiMgICAgICAgUmVxdWlyZSBpbnRlZ3JpdHkgcHJvdGVjdGlvbiAocHJldmVu dCBoaWphY2tpbmcpDQojICAgICAgIFJlcXVpcmUgMTEyLWJpdCAoM0RFUyBvciBiZXR0ZXIpIGVu Y3J5cHRpb24gZm9yIHVwZGF0ZXMNCiMgICAgICAgUmVxdWlyZSA2My1iaXQgZW5jcnlwdGlvbiBm b3Igc2ltcGxlIGJpbmQNCiMgc2VjdXJpdHkgc3NmPTEgdXBkYXRlX3NzZj0xMTIgc2ltcGxlX2Jp bmQ9NjQNCnNlY3VyaXR5IHNzZj0wIHVwZGF0ZV9zc2Y9MTI4DQojc2VjdXJpdHkgc3NmPTEyOA0K Iw0KVExTQ2VydGlmaWNhdGVGaWxlIC91c3IvbG9jYWwvZXRjL29wZW5sZGFwL2NlcnQuY3J0DQpU TFNDZXJ0aWZpY2F0ZUtleUZpbGUgL3Vzci9sb2NhbC9ldGMvb3BlbmxkYXAvY2VydC5rZXkNClRM U0NBQ2VydGlmaWNhdGVGaWxlIC91c3IvbG9jYWwvZXRjL29wZW5sZGFwL2NlcnQuY3J0DQojDQoj IFNhbXBsZSBhY2Nlc3MgY29udHJvbCBwb2xpY3k6DQojICAgICAgIFJvb3QgRFNFOiBhbGxvdyBh bnlvbmUgdG8gcmVhZCBpdA0KIyAgICAgICBTdWJzY2hlbWEgKHN1YillbnRyeSBEU0U6IGFsbG93 IGFueW9uZSB0byByZWFkIGl0DQojICAgICAgIE90aGVyIERTRXM6DQojICAgICAgICAgICAgICAg QWxsb3cgc2VsZiB3cml0ZSBhY2Nlc3MNCiMgICAgICAgICAgICAgICBBbGxvdyBhdXRoZW50aWNh dGVkIHVzZXJzIHJlYWQgYWNjZXNzDQojICAgICAgICAgICAgICAgQWxsb3cgYW5vbnltb3VzIHVz ZXJzIHRvIGF1dGhlbnRpY2F0ZQ0KIyAgICAgICBEaXJlY3RpdmVzIG5lZWRlZCB0byBpbXBsZW1l bnQgcG9saWN5Og0KIw0KIyBpZiBubyBhY2Nlc3MgY29udHJvbHMgYXJlIHByZXNlbnQsIHRoZSBk ZWZhdWx0IHBvbGljeQ0KIyBhbGxvd3MgYW55b25lIGFuZCBldmVyeW9uZSB0byByZWFkIGFueXRo aW5nIGJ1dCByZXN0cmljdHMNCiMgdXBkYXRlcyB0byByb290ZG4uICAoZS5nLiwgImFjY2VzcyB0 byAqIGJ5ICogcmVhZCIpDQojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj DQojIHBlcm1pc3Npb25zDQojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMN Ci4NCi4NCi5zZWNyZXQNCi4NCi4NCi4NCiMNCiMgR2xvYmFsIHNlY3Rpb24NCiAgICAgICBzZXJ2 ZXJJRCAgICAxDQojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KIyBCREIgZGF0YWJhc2UgZGVmaW5pdGlvbnMNCiMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjDQojDQpkYXRhYmFzZSAgICAgICAgYmRiDQpzdWZmaXggICAgICAgICAgImRj PWliYSxkYz1sb2NhbCINCnJvb3RkbiAgICAgICAgICAiZGM9aWJhLGRjPWxvY2FsIg0KbW9uaXRv cmluZyAgICAgIG9mZg0KIyBDbGVhcnRleHQgcGFzc3dvcmRzLCBlc3BlY2lhbGx5IGZvciB0aGUg cm9vdGRuLCBzaG91bGQNCiMgYmUgYXZvaWQuICBTZWUgc2xhcHBhc3N3ZCg4KSBhbmQgc2xhcGQu Y29uZig1KSBmb3IgZGV0YWlscy4NCiMgVXNlIG9mIHN0cm9uZyBhdXRoZW50aWNhdGlvbiBlbmNv dXJhZ2VkLg0Kcm9vdHB3ICAgICAgICAgIHtTU0hBfQ0KIyBUaGUgZGF0YWJhc2UgZGlyZWN0b3J5 IE1VU1QgZXhpc3QgcHJpb3IgdG8gcnVubmluZyBzbGFwZCBBTkQNCiMgc2hvdWxkIG9ubHkgYmUg YWNjZXNzaWJsZSBieSB0aGUgc2xhcGQgYW5kIHNsYXAgdG9vbHMuDQojIE1vZGUgNzAwIHJlY29t bWVuZGVkLg0KZGlyZWN0b3J5ICAgICAgIC91c3IvbG9jYWwvdmFyL2liYS1kYXRhDQojIEluZGlj ZXMgdG8gbWFpbnRhaW4NCmluZGV4ICAgb2JqZWN0Q2xhc3MgICAgIGVxDQppbmRleCAgIGNuICAg ICAgICAgICAgICBlcQ0KaW5kZXggICBvdSAgICAgICAgICAgICAgZXENCmluZGV4ICAgZ2lkTnVt YmVyICAgICAgIGVxDQppbmRleCAgIHVpZE51bWJlciAgICAgICBlcQ0KaW5kZXggICBlbnRyeVVV SUQgICAgICAgZXENCmluZGV4ICAgZW50cnlDU04gICAgICAgIGVxDQppbmRleCAgIG1lbWJlciAg ICAgICAgICBlcQ0KIw0KaW5kZXggbG9naW5TaGVsbCBlcQ0KaW5kZXggdWlkIGVxLHByZXMsc3Vi DQppbmRleCBtZW1iZXJVaWQgZXEscHJlcyxzdWINCmluZGV4IHVuaXF1ZU1lbWJlciBlcSxwcmVz DQppbmRleCBzYW1iYVNJRCBlcQ0KaW5kZXggc2FtYmFQcmltYXJ5R3JvdXBTSUQgZXENCmluZGV4 IHNhbWJhR3JvdXBUeXBlIGVxDQppbmRleCBzYW1iYVNJRExpc3QgZXENCmluZGV4IHNhbWJhRG9t YWluTmFtZSBlcQ0KaW5kZXggZGVmYXVsdCBzdWINCmluZGV4IG1vZGlmeVRpbWVzdGFtcCBlcQ0K Iw0KIyBMZXQgdGhlIHJlcGxpY2EgRE4gaGF2ZSBsaW1pdGxlc3Mgc2VhcmNoZXMNCmxpbWl0cyBk bi5leGFjdD0ib3U9UmVwbGljYXRvcixjbj1NYW5hZ2VycyxkYz1pYmEsZGM9bG9jYWwiIHRpbWUu c29mdD11bmxpbWl0ZWQgdGltZS5oYXJkPXVubGltaXRlZCBzaXplLnNvZnQ9dW5saW1pdGVkIHNp emUuaGFyZD11bmxpbWl0ZWQNCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0Kb3ZlcmxheSBzbWJrNXB3ZA0KIyAg ICAgICBzbWJrNXB3ZC1lbmFibGUgICAgICAgICBzYW1iYQ0KICAgICAgICBzbWJrNXB3ZC1tdXN0 LWNoYW5nZSAgICA1MTg0MDAwDQpvdmVybGF5IHN5bmNwcm92DQpzeW5jcHJvdi1jaGVja3BvaW50 IDEwIDUNCiMNCiMgc3luY3JlcGwgZGlyZWN0aXZlDQpzeW5jcmVwbCByaWQ9MDU2IHByb3ZpZGVy PWxkYXA6Ly8xMC4wLjEwMC42IGJpbmRtZXRob2Q9c2ltcGxlDQogICAgICAgICBiaW5kZG49Im91 PVJlcGxpY2F0b3IsY249TWFuYWdlcnMsZGM9aWJhLGRjPWxvY2FsIiBjcmVkZW50aWFscz1YeHh4 eA0KICAgICAgICAgc2VhcmNoYmFzZT0iZGM9aWJhLGRjPWxvY2FsIg0KICAgICAgICAgc2NoZW1h Y2hlY2tpbmc9b24gdHlwZT1yZWZyZXNoQW5kUGVyc2lzdCB0aW1lb3V0PTMgcmV0cnk9IjYwIDUg MTIwICsiDQogICAgICAgICBzdGFydHRscz15ZXMNCiMgICAgICAgICB0bHNfY2VydD0vdXNyL2xv Y2FsL2V0Yy9vcGVubGRhcC9zMDYuY3J0DQojICAgICAgICAgdGxzX2tleT0vdXNyL2xvY2FsL2V0 Yy9vcGVubGRhcC9zMDYua2V5DQojICAgICAgICAgdGxzX2NhY2VydD0vdXNyL2xvY2FsL2V0Yy9v cGVubGRhcC9zMDYuY3J0DQptaXJyb3Jtb2RlIG9uDQojDQpvdmVybGF5IHBwb2xpY3kNCnBwb2xp Y3lfZGVmYXVsdCAiY249ZGVmYXVsdHB3cG9saWN5LG91PXB3cG9saWNpZXMsZGM9aWJhLGRjPWxv Y2FsIg0KcHBvbGljeV91c2VfbG9ja291dA0KcHBvbGljeV9oYXNoX2NsZWFydGV4dA0KIw0K --_003_DB4PR03MB0911E60223F1AE5F6D332DA881750DB4PR03MB0911eurp_ Content-Type: text/plain; name="slapd.consumer.conf.txt" Content-Description: slapd.consumer.conf.txt Content-Disposition: attachment; filename="slapd.consumer.conf.txt"; size=4728; creation-date="Tue, 04 Aug 2015 14:48:34 GMT"; modification-date="Tue, 04 Aug 2015 14:48:34 GMT" Content-Transfer-Encoding: base64 Iw0KIyBTZWUgc2xhcGQuY29uZig1KSBmb3IgZGV0YWlscyBvbiBjb25maWd1cmF0aW9uIG9wdGlv bnMuDQojIFRoaXMgZmlsZSBzaG91bGQgTk9UIGJlIHdvcmxkIHJlYWRhYmxlLg0KIw0KaW5jbHVk ZSAgICAgICAgIC91c3IvbG9jYWwvZXRjL29wZW5sZGFwL3NjaGVtYS9jb3JlLnNjaGVtYQ0KaW5j bHVkZSAgICAgICAgIC91c3IvbG9jYWwvZXRjL29wZW5sZGFwL3NjaGVtYS9jb3NpbmUuc2NoZW1h DQppbmNsdWRlICAgICAgICAgL3Vzci9sb2NhbC9ldGMvb3BlbmxkYXAvc2NoZW1hL25pcy5zY2hl bWENCmluY2x1ZGUgICAgICAgICAvdXNyL2xvY2FsL2V0Yy9vcGVubGRhcC9zY2hlbWEvaW5ldG9y Z3BlcnNvbi5zY2hlbWENCmluY2x1ZGUgICAgICAgICAvdXNyL2xvY2FsL2V0Yy9vcGVubGRhcC9z Y2hlbWEvc2FtYmEuc2NoZW1hDQppbmNsdWRlICAgICAgICAgL3Vzci9sb2NhbC9ldGMvb3Blbmxk YXAvc2NoZW1hL3Bwb2xpY3kuc2NoZW1hDQppbmNsdWRlICAgICAgICAgL3Vzci9sb2NhbC9ldGMv b3BlbmxkYXAvc2NoZW1hL2liYS5zY2hlbWENCmluY2x1ZGUgICAgICAgICAvdXNyL2xvY2FsL2V0 Yy9vcGVubGRhcC9zY2hlbWEvcmFkaXVzLnNjaGVtYQ0KIw0KIyBEZWZpbmUgZ2xvYmFsIEFDTHMg dG8gZGlzYWJsZSBkZWZhdWx0IHJlYWQgYWNjZXNzLg0KDQojIERvIG5vdCBlbmFibGUgcmVmZXJy YWxzIHVudGlsIEFGVEVSIHlvdSBoYXZlIGEgd29ya2luZyBkaXJlY3RvcnkNCiMgc2VydmljZSBB TkQgYW4gdW5kZXJzdGFuZGluZyBvZiByZWZlcnJhbHMuDQojcmVmZXJyYWwgICAgICAgbGRhcDov L3Jvb3Qub3BlbmxkYXAub3JnDQoNCnBpZGZpbGUgICAgICAgICAvdXNyL2xvY2FsL3Zhci9ydW4v c2xhcGQucGlkDQphcmdzZmlsZSAgICAgICAgL3Vzci9sb2NhbC92YXIvcnVuL3NsYXBkLmFyZ3MN CmxvZ2xldmVsICAgICAgICAyNTYNCiMNCiMgTG9hZCBkeW5hbWljIGJhY2tlbmQgbW9kdWxlczoN CiMgICAgICAgY2hlY2tfcGFzc3dvcmQgaXMgSUJBcyBzcGVjaWFsIHBhc3N3b3JkIGNvbXBsaWFu Y2UgbW9kdWxlDQojICAgICAgIHNtYms1cHdkIGlzIGEgbW9kdWxlIHRoYXQgdXBkYXRlcyBzYW1i YXB3ZHMgd2hlbiB1c2VycHdkcyBjaGFuZ2UNCm1vZHVsZXBhdGggICAgICAvdXNyL2xvY2FsL2V0 Yy9vcGVubGRhcC9pYmENCm1vZHVsZWxvYWQgICAgICBjaGVja19wYXNzd29yZC5zbw0KbW9kdWxl bG9hZCAgICAgIHNtYms1cHdkLnNvDQojIG1vZHVsZXBhdGggICAgL3Vzci9sb2NhbC9saWJleGVj L29wZW5sZGFwDQojIG1vZHVsZWxvYWQgICAgYmFja19iZGIubGENCiMgbW9kdWxlbG9hZCAgICBi YWNrX2hkYi5sYQ0KIyBtb2R1bGVsb2FkICAgIGJhY2tfbGRhcC5sYQ0KIw0KIyBTYW1wbGUgc2Vj dXJpdHkgcmVzdHJpY3Rpb25zDQojICAgICAgIFJlcXVpcmUgaW50ZWdyaXR5IHByb3RlY3Rpb24g KHByZXZlbnQgaGlqYWNraW5nKQ0KIyAgICAgICBSZXF1aXJlIDExMi1iaXQgKDNERVMgb3IgYmV0 dGVyKSBlbmNyeXB0aW9uIGZvciB1cGRhdGVzDQojICAgICAgIFJlcXVpcmUgNjMtYml0IGVuY3J5 cHRpb24gZm9yIHNpbXBsZSBiaW5kDQpzZWN1cml0eSBzc2Y9MCB1cGRhdGVfc3NmPTEyOA0KIyAg ICAgICAgICAgICAgICBzaW1wbGVfYmluZD0xMjgNCiNzZWN1cml0eSBzc2Y9MTI4DQojDQpUTFND ZXJ0aWZpY2F0ZUZpbGUgL3Vzci9sb2NhbC9ldGMvb3BlbmxkYXAvY2VydC5jcnQNClRMU0NlcnRp ZmljYXRlS2V5RmlsZSAvdXNyL2xvY2FsL2V0Yy9vcGVubGRhcC9jZXJ0LmtleQ0KVExTQ0FDZXJ0 aWZpY2F0ZUZpbGUgL3Vzci9sb2NhbC9ldGMvb3BlbmxkYXAvY2VydC5jcnQNCiMNCiMgU2FtcGxl IGFjY2VzcyBjb250cm9sIHBvbGljeToNCiMgICAgICAgUm9vdCBEU0U6IGFsbG93IGFueW9uZSB0 byByZWFkIGl0DQojICAgICAgIFN1YnNjaGVtYSAoc3ViKWVudHJ5IERTRTogYWxsb3cgYW55b25l IHRvIHJlYWQgaXQNCiMgICAgICAgT3RoZXIgRFNFczoNCiMgICAgICAgICAgICAgICBBbGxvdyBz ZWxmIHdyaXRlIGFjY2Vzcw0KIyAgICAgICAgICAgICAgIEFsbG93IGF1dGhlbnRpY2F0ZWQgdXNl cnMgcmVhZCBhY2Nlc3MNCiMgICAgICAgICAgICAgICBBbGxvdyBhbm9ueW1vdXMgdXNlcnMgdG8g YXV0aGVudGljYXRlDQojICAgICAgIERpcmVjdGl2ZXMgbmVlZGVkIHRvIGltcGxlbWVudCBwb2xp Y3k6DQojDQojIGlmIG5vIGFjY2VzcyBjb250cm9scyBhcmUgcHJlc2VudCwgdGhlIGRlZmF1bHQg cG9saWN5DQojIGFsbG93cyBhbnlvbmUgYW5kIGV2ZXJ5b25lIHRvIHJlYWQgYW55dGhpbmcgYnV0 IHJlc3RyaWN0cw0KIyB1cGRhdGVzIHRvIHJvb3Rkbi4gIChlLmcuLCAiYWNjZXNzIHRvICogYnkg KiByZWFkIikNCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMNCiMgcGVy bWlzc2lvbnMNCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KLg0KLg0K Lg0Kc2VjcmV0DQouDQouDQouDQojIGFueW9uZSBlbHNlIGdldHMgbm90aGluZyAtIHNvIHB3J3Mg YXJlbid0IGxpc3RlZCB1bmxlc3MgeW91IGFyZSB0aGUgdXNlciBvcg0KIw0KIw0KIyBHbG9iYWwg c2VjdGlvbg0KICAgICAgIHNlcnZlcklEICAgIDINCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjDQojIEJEQiBkYXRh YmFzZSBkZWZpbml0aW9ucw0KIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMNCiMNCmRhdGFiYXNlICAgICAgICBiZGIN CnN1ZmZpeCAgICAgICAgICAiZGM9aWJhLGRjPWxvY2FsIg0Kcm9vdGRuICAgICAgICAgICJkYz1p YmEsZGM9bG9jYWwiDQptb25pdG9yaW5nICAgICAgb2ZmDQojIENsZWFydGV4dCBwYXNzd29yZHMs IGVzcGVjaWFsbHkgZm9yIHRoZSByb290ZG4sIHNob3VsZA0KIyBiZSBhdm9pZC4gIFNlZSBzbGFw cGFzc3dkKDgpIGFuZCBzbGFwZC5jb25mKDUpIGZvciBkZXRhaWxzLg0KIyBVc2Ugb2Ygc3Ryb25n IGF1dGhlbnRpY2F0aW9uIGVuY291cmFnZWQuDQpyb290cHcgICAgICAgICAge1NTSEF9DQojIFRo ZSBkYXRhYmFzZSBkaXJlY3RvcnkgTVVTVCBleGlzdCBwcmlvciB0byBydW5uaW5nIHNsYXBkIEFO RA0KIyBzaG91bGQgb25seSBiZSBhY2Nlc3NpYmxlIGJ5IHRoZSBzbGFwZCBhbmQgc2xhcCB0b29s cy4NCiMgTW9kZSA3MDAgcmVjb21tZW5kZWQuDQpkaXJlY3RvcnkgICAgICAgL3Vzci9sb2NhbC92 YXIvaWJhLWRhdGENCiMgSW5kaWNlcyB0byBtYWludGFpbg0KaW5kZXggICBvYmplY3RDbGFzcyAg ICAgZXENCmluZGV4ICAgY24gICAgICAgICAgICAgIGVxDQppbmRleCAgIG91ICAgICAgICAgICAg ICBlcQ0KaW5kZXggICBnaWROdW1iZXIgICAgICAgZXENCmluZGV4ICAgdWlkTnVtYmVyICAgICAg IGVxDQppbmRleCAgIGVudHJ5VVVJRCAgICAgICBlcQ0KaW5kZXggICBlbnRyeUNTTiAgICAgICAg ZXENCmluZGV4ICAgbWVtYmVyICAgICAgICAgIGVxDQojDQppbmRleCBsb2dpblNoZWxsIGVxDQpp bmRleCB1aWQgZXEscHJlcyxzdWINCmluZGV4IG1lbWJlclVpZCBlcSxwcmVzLHN1Yg0KaW5kZXgg dW5pcXVlTWVtYmVyIGVxLHByZXMNCmluZGV4IHNhbWJhU0lEIGVxDQppbmRleCBzYW1iYVByaW1h cnlHcm91cFNJRCBlcQ0KaW5kZXggc2FtYmFHcm91cFR5cGUgZXENCmluZGV4IHNhbWJhU0lETGlz dCBlcQ0KaW5kZXggc2FtYmFEb21haW5OYW1lIGVxDQppbmRleCBkZWZhdWx0IHN1Yg0KaW5kZXgg bW9kaWZ5VGltZXN0YW1wIGVxDQojDQojIExldCB0aGUgcmVwbGljYSBETiBoYXZlIGxpbWl0bGVz cyBzZWFyY2hlcw0KbGltaXRzIGRuLmV4YWN0PSJvdT1SZXBsaWNhdG9yLGNuPU1hbmFnZXJzLGRj PWliYSxkYz1sb2NhbCIgdGltZS5zb2Z0PXVubGltaXRlZCB0aW1lLmhhcmQ9dW5saW1pdGVkIHNp emUuc29mdD11bmxpbWl0ZWQgc2l6ZS5oYXJkPXVubGltaXRlZA0KIw0KIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj DQpvdmVybGF5IHNtYms1cHdkDQpvdmVybGF5IHN5bmNwcm92DQpzeW5jcHJvdi1jaGVja3BvaW50 IDEwIDUNCiMNCiMgc3luY3JlcGwgZGlyZWN0aXZlDQpzeW5jcmVwbCByaWQ9MDU2IHByb3ZpZGVy PWxkYXA6Ly8xMC4wLjEwMC41IGJpbmRtZXRob2Q9c2ltcGxlDQogICAgICAgICBiaW5kZG49Im91 PVJlcGxpY2F0b3IsY249TWFuYWdlcnMsZGM9aWJhLGRjPWxvY2FsIiBjcmVkZW50aWFscz1YeHh4 eA0KICAgICAgICAgc2VhcmNoYmFzZT0iZGM9aWJhLGRjPWxvY2FsIg0KICAgICAgICAgc2NoZW1h Y2hlY2tpbmc9b24gdHlwZT1yZWZyZXNoQW5kUGVyc2lzdCB0aW1lb3V0PTMgcmV0cnk9IjYwIDUg MTIwICsiDQogICAgICAgICBzdGFydHRscz15ZXMNCiMgICAgICAgICB0bHNfY2VydD0vdXNyL2xv Y2FsL2V0Yy9vcGVubGRhcC9zMDUuY3J0DQojICAgICAgICAgdGxzX2tleT0vdXNyL2xvY2FsL2V0 Yy9vcGVubGRhcC9zMDUua2V5DQojICAgICAgICAgdGxzX2NhY2VydD0vdXNyL2xvY2FsL2V0Yy9v cGVubGRhcC9zMDUuY3J0DQptaXJyb3Jtb2RlIG9uDQojDQpvdmVybGF5IHBwb2xpY3kNCnBwb2xp Y3lfZGVmYXVsdCAiY249ZGVmYXVsdHB3cG9saWN5LG91PXB3cG9saWNpZXMsZGM9aWJhLGRjPWxv Y2FsIg0KcHBvbGljeV91c2VfbG9ja291dA0KcHBvbGljeV9oYXNoX2NsZWFydGV4dA0KIw0K --_003_DB4PR03MB0911E60223F1AE5F6D332DA881750DB4PR03MB0911eurp_--

1 0

Re: (ITS#8212) slapd stops on consumer node
by michael＠stroeder.com 04 Aug '15

04 Aug '15

Steen.brandtmar(a)ibapplications.com wrote: > We are running two servers in mirrormode. > When we run ldappasswd on provider node all is OK and passwords are changed in > bdb. Logfile shows PASSMOD on relevant uid. > When we run the same ldappasswd command on consumer node, slapd stops abruptly > on this node and must be started manually. Could you please retry with 2.4.41? If it's still a problem with 2.4.41 a stripped down config for reproducing the issue would be good. Ciao, Michael.

1 0

(ITS#8212) slapd stops on consumer node
by Steen.brandtmar＠ibapplications.com 04 Aug '15

04 Aug '15

Full_Name: Steen Brandtmar Version: 2.4.40 OS: Linux Ubuntu 12.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (86.48.99.242) Hi We are running two servers in mirrormode. When we run ldappasswd on provider node all is OK and passwords are changed in bdb. Logfile shows PASSMOD on relevant uid. When we run the same ldappasswd command on consumer node, slapd stops abruptly on this node and must be started manually.

1 0

(ITS#8211) ssf does not reflect actual security of connection
by hkario＠redhat.com 03 Aug '15

03 Aug '15

Full_Name: Hubert Kario Version: all OS: Linux URL: Submission from: (NULL) (213.175.37.10) Section "14.2.1. Security Strength Factors"[1] states "A SSF greater than one (>1) roughly correlates to the effective encryption key length.". This is not the case more often than not. Problem is that ssf as it is calculated now doesn't take into consideration all the cryptographic primitives in use. In other words, a connection that uses a 512 bit RSA certificates and negotiates TLS_RSA_WITH_AES_128_CBC_SHA (AES256-SHA) certainly does not provide security equivalent to "modern strong ciphers"[2][3] and should be awarded "256". Similarly a connection that uses 512 bit DH parameters and negotiates TLS_DHE_RSA_WITH_AES_256_CBC_SHA (DHE-RSA-AES256-SHA) does not provide security that should be awarded "256"[5]. In fact, recommending use of high key sizes[2] will cause the connection to use _less_ secure CBC ciphersuites[5] with clients that support AEAD ciphersuites with AES-128 only (like Thunderbird and Firefox do). Section 8.4.9[2] also calls RC4 a "modern strong cipher", most cryptographers disagree[6]. So I think either: 1). ssf needs to be redefined to consider any value higher that "2" to be equal, and requiring the server administrators to enable only ciphersuites they consider secure, or 2). the whole code that calculates ssf needs to be updated to take into account many more things: * use of AEAD * use of Encrypt-then-MAC * the protocol version used (both because TLS1.0 specific attacks[7] as wewell as the use of SHA1+MD5 for signatures which limits the connection security to 80 bits[8] (optimistically) if client certificates are in use in TLS < 1.2) * encryption algorithm on session tickets * current state of attacks on a given ciphersuite * the size of ECDHE curve, FFDHE prime or server certificate key size, depending on ciphersuite negotiated * the signature algorithm used in Certificate Verify message * the key size of client certificate * the signature on the client certificate and key sizes in CA certificates * the HMAC used * key size of the symmetric cipher * (probably other things I didn't think about) 1 - http://www.openldap.org/doc/admin24/security.html 2 - http://w.w.openldap.org/doc/admin24/access-control.html section 8.4.9 3 - https://freakattack.com/ 4 - https://weakdh.org/ 5 - http://www.isg.rhul.ac.uk/tls/Lucky13.html 6 - https://tools.ietf.org/html/rfc7465 7 - https://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack 8 - https://www.iacr.org/cryptodb/archive/2004/CRYPTO/1472/1472.pdf

1 0

Re: (ITS#8209) Broken MDB_CP_COMPACT threading
by h.b.furuseth＠usit.uio.no 03 Aug '15

03 Aug '15

Okay, that was one confused ITS in response to equally confused code. Trying again. Draft fixes in my updated branch "mdb/copyfd1" (non-fast-forward). It's broken if mdb_env_copythr() has a write error: * copyfd1 can (A) overrun buffer mc_wlen, and (B) hang, if if cthr_toggle() is in cond_wait() when the error occurs: It sets mc_new and returns success. cwalk() proceeds to write at mc_wbuf+mc_wlen, but copythr() did not reset mc_wlen. Then copyfd1() waits for the now-dead copythr() to clear mc_new. Fixes: (A) join the if(mc_status) and while(mc_new==1) in cthr_toggle. (B) Drop the wait before THREAD_FINISH(), it seems pointless. Both Posix and Windows doc say that THREAD_FINISH waits. Or if Windows needs it for some reason, then copythr must live until it receives mc_new=-1, so it can set mc_new=0. * copyfd1() loses any error from the final cthr_toggle(). Fix: Return rc ? rc : my.mc_status. Tested on Linux with fake write errors, with/without fixes. While not a bug, I also see no point in both threads' initial waits. copyfd1() can own the buffer initially (set mc_new=0). I'm guessing the waits are there because the code tries to guide the threads from step to step, but it broke because you didn't think of every possibility. It's easier to define and maintain one cond_wait state per thread and keep things consistent there. More on error checking: copyfd1() omits most error checking and the cleanup after errors. E.g. it does not tell copythr to finish if txn_begin fails. Each thread is slow to react to errors in the other thread. I/O will cease quicker if both threads set and check mc_status. If so, mc_status can no longer be part of the cond_wait condition, since it won't be mutex-protected. So the threads might chat a bit more before finishing. I'd rename mc_status -> mc_error. "while (!my->mc_error && ...)" is quite self-explanatory, unlike "while (!my->mc_status && ...)". About lock/unlock outside vs. inside the loop: When outside, copythr() must block for the threads to exchange buffers. When inside, the slowest thread does not block, but there are more lock/unlock/wait calls. Testing: Locks inside is clearly faster on tmpfs. On a regular FS I don't know - it may have been a bit slower, but times varied more than the difference. Finally, cwalk() could re-use the page buffers it mallocs. -- Hallvard

1 0

(ITS#8210) slapd-sock: second subsequent bind fails
by michael＠stroeder.com 01 Aug '15

01 Aug '15

Full_Name: Version: OS: URL: Submission from: (NULL) (79.223.48.67) When using *one* connection for sending *two* sequential bind requests slapd-sock blocks. I have a working test case which I can send upon request.

1 0

Re: (ITS#8207) ppolicy: pwdMinLength not checked if pwdInHistory == 0
by michael＠stroeder.com 01 Aug '15

01 Aug '15

IanB wrote: > I've attempted to test with OpenLDAP 2.4.41 but cannot get password changing > to work at all, constantly getting error: "passwd: Authentication token > manipulation error" Greping through the source this message is output from slapo-nssov. Are you sure that you re-built and installed slapo-nssov from 2.4.41? Also you should always first test with ldappasswd command-line tool to avoid false interaction with other software. What else do you have configured? > Unfortunately, I cannot spend more time on this now. What does that mean? If you don't want to work on this ITS any further it's probably the best to close it. Ciao, Michael.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs