ITS#7208
by andre.cardinal＠bell.ca
--_000_7B0942425E628C468907C3029A0F33E49DB58BEAMBX16bellcorpbc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
In order to speed up reproducing the bug, I changed the keep_alive_interval=
to 600000 (10 minutes)
The Slave coredumped after 10 minutes of not being able to communicate with=
it's Master.
--_000_7B0942425E628C468907C3029A0F33E49DB58BEAMBX16bellcorpbc_
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=3DContent-Type content=
=3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros=
oft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-CA link=3Dblue vli=
nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal>In order to spee=
d up reproducing the bug, I changed the keep_alive_interval to 600000 (10 m=
inutes)<o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3D=
MsoNormal>The Slave coredumped after 10 minutes of not being able to commun=
icate with it’s Master.<o:p></o:p></p></div></body></html>=
--_000_7B0942425E628C468907C3029A0F33E49DB58BEAMBX16bellcorpbc_--
11 years, 8 months
Re: (ITS#7208) Replica coredumps in syncrepl mode
by michael＠stroeder.com
This is a cryptographically signed message in MIME format.
--------------ms080104040202090104060807
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
andre.cardinal(a)bell.ca wrote:
> Typo on my part
>
> It is 2.4.24
Anyway you should try to reproduce this with 2.4.30 since there have been=
=20
numerous fixes to syncrepl since 2.4.24:
http://www.openldap.org/devel/gitweb.cgi?p=3Dopenldap.git;a=3Dblob;f=3DCH=
ANGES;h=3D1c68a45c430b4d3ebaea83294c05c242a3ba91bf;hb=3Drefs/heads/OPENLD=
AP_REL_ENG_2_4
Ciao, Michael.
> -----Original Message-----
> From: Michael Str=F6der [mailto:michael@stroeder.com]
> Sent: March-14-12 9:41 AM
> To: Cardinal, Andre (520972)
> Cc: openldap-its(a)openldap.org
> Subject: Re: (ITS#7208) Replica coredumps in syncrepl mode
>
> andre.cardinal(a)bell.ca wrote:
>> Full_Name: Andre Cardinal
>> Version: 2.2.24
>
> Are you really using 2.2.24? This is an ancient version. 2.2.x has been=
set to
> historic years ago.
>
> Could you please try to reproduce this with currently recent release 2.=
4.30?
>
> Ciao, Michael.
--------------ms080104040202090104060807
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC
BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx
MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj
MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd
NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV
hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/
0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ
NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH
AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy
IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl
cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB
BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov
L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq
hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj
/E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd
dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH
SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ
AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63
TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT
QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ
R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv
n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy
D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB
gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx
IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1
cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDMxNDE0MDQzMVowIwYJKoZIhvcNAQkEMRYE
FJkgOqb2gdGaFMxe/XPrSXGdLw6HMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG
CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq
hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc
BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n
IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG
CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6
Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh
MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE
ggEAAaOKi3q8/1dU7oRpxVYTBXb8WNOy0GFbA7awAAfhetQq68cq/+HwY5H+grPXuMZdOgce
WJ09MEeAHlz4aExR2qOsClu5EBpHQoTOu20U8ByFpUU1xS6x5ZB7wv4JN8GpHe7sV/nTSDcJ
bpA0kjurXc6UkwfLionQKJkdz//PTzkdCw+wGsz4UiRRayEbcq4BRi5KTp1IewrQwcid/qaN
hfNATAhn1dbFfBv4mvyIYyEnSNG85XYwRdAyVSl8hVsfgWmSH6K/goGxeEMlnWPNxBk7F9ui
AXpsiljAnNn4vl/uny5SFPKJkkn4mtDO7jK8RZKvxU+Pb2DBkjmBIaM/dgAAAAAAAA==
--------------ms080104040202090104060807--
11 years, 8 months
RE: (ITS#7208) Replica coredumps in syncrepl mode
by andre.cardinal＠bell.ca
Typo on my part
It is 2.4.24
-----Original Message-----
From: Michael Ströder [mailto:michael@stroeder.com]
Sent: March-14-12 9:41 AM
To: Cardinal, Andre (520972)
Cc: openldap-its(a)openldap.org
Subject: Re: (ITS#7208) Replica coredumps in syncrepl mode
andre.cardinal(a)bell.ca wrote:
> Full_Name: Andre Cardinal
> Version: 2.2.24
Are you really using 2.2.24? This is an ancient version. 2.2.x has been set to
historic years ago.
Could you please try to reproduce this with currently recent release 2.4.30?
Ciao, Michael.
11 years, 8 months
Re: (ITS#7208) Replica coredumps in syncrepl mode
by michael＠stroeder.com
This is a cryptographically signed message in MIME format.
--------------ms050408060208030303010805
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
andre.cardinal(a)bell.ca wrote:
> Full_Name: Andre Cardinal
> Version: 2.2.24
Are you really using 2.2.24? This is an ancient version. 2.2.x has been s=
et to=20
historic years ago.
Could you please try to reproduce this with currently recent release 2.4.=
30?
Ciao, Michael.
--------------ms050408060208030303010805
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC
BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx
MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj
MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd
NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV
hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/
0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ
NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH
AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy
IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl
cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB
BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov
L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq
hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj
/E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd
dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH
SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ
AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63
TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT
QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ
R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv
n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy
D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB
gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx
IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1
cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDMxNDEzNDA0NFowIwYJKoZIhvcNAQkEMRYE
FPblbthmkMffgP3cgCbuBPtlezT2MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG
CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq
hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc
BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n
IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG
CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6
Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh
MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE
ggEAklodZ8Q0BtBXDb6m8/1q/UI1uoBf+3YPCUPFCgJteK48aBPZDpd6PQuhapmF9z+CuTJk
JXV1J6uro8pBxQddbe6u8nPM2N9uwR9PVw58CKM3je2K7b2h10umwmiWZKiN/fG26nGFBM7B
HKRoQw/oZ1lbsXH4kF22dMt9KRDL+vfNs5VfnNFuB9K7fxKySxB98gWbsPFx5giPOLLLqdKd
SKjSK2+myZw8gTvKVfgI3fMOelvXvMtvTlkKMOY+12dECeFrbe51g5N1h0+rP08XnbrkMJsT
H4Uz3DfJIt9tJkAXAiZ+l9sXzsxv2unUpGehzogR7Ss/DBKKWW+/Gb2hcQAAAAAAAA==
--------------ms050408060208030303010805--
11 years, 8 months
(ITS#7208) Replica coredumps in syncrepl mode
by andre.cardinal＠bell.ca
Full_Name: Andre Cardinal
Version: 2.2.24
OS: Solaris 10
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (206.47.249.247)
Replica core dumps if unable to contact it's Master after 2 hours.
Replica is set to refresh and persist.
To reproduce...
Shut down slapd on Master server and/or, if multihomed server, shutdown the
replication interface.
After 2 hours (the os keep_alive_interval) the log will report:
Feb 28 12:30:15 dpdsrass1 slapd[25552]: [ID 539778 local4.debug] do_syncrep2:
rid=123 (-1) Can't contact LDAP server
Feb 28 12:30:15 dpdsrass1 slapd[25552]: [ID 664938 local4.debug] do_syncrepl:
rid=123 rc -1 retrying
And ldap will coredump shortly there after.
The log entry mentionned above do appear in the log (every 2 hours) if there is
no traffic from the Master to the Slave and the Master can be contacted, so no
coredump.
11 years, 8 months
(ITS#7207) Re-binding to a failed connection segfaults
by jsynacek＠redhat.com
Full_Name: Jan Synacek
Version: 2.4.30
OS: Fedora 16
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (209.132.186.34)
I've created a small reproducer, that calls ldap_sasl_interactive_bind_s after
it has been called once and failed, which causes a segfault.
I've traced this bug with gdb:
$ gdb ./reproducer
GNU gdb (GDB) Fedora (7.3.50.20110722-10.fc16)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from
/home/jsynacek/work/bz784989-openldap-rebinding/reproducer...done.
(gdb) r
Starting program: /home/jsynacek/work/bz784989-openldap-rebinding/reproducer
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
ldap_sasl_interactive_bind: user selected: GSSAPI
ldap_int_sasl_bind: GSSAPI
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP localhost:636
ldap_new_socket: 7
ldap_prepare_socket: 7
ldap_connect_to_host: Trying ::1 636
ldap_pvt_connect: fd: 7 tm: -1 async: 0
TLS: error: tlsm_PR_Recv returned 0 - error 21:Is a directory
TLS: error: connect - force handshake failure: errno 21 - moznss error -5938
TLS: can't connect: TLS error -5938:Encountered end of file.
ldap_msgfree
ldap_err2string
bind failed: Can't contact LDAP server, retrying for fun and profit!
ldap_sasl_interactive_bind: user selected: GSSAPI
ldap_int_sasl_bind: GSSAPI
Program received signal SIGSEGV, Segmentation fault.
ldap_int_sasl_bind (ld=0x603130, dn=0x0, mechs=0x401a30 "GSSAPI", sctrls=0x0,
cctrls=0x0, flags=1,
interact=0x401660 <lutil_sasl_interact>, defaults=0x60cae0, result=0x0,
rmech=0x7fffffffd878,
msgid=0x7fffffffd88c) at ../../../libraries/libldap/cyrus.c:444
444 oldctx = ld->ld_defconn->lconn_sasl_authctx;
(gdb) p ld->ldc->ldc_defconn
$1 = (LDAPConn *) 0x0
If you set slapd to use TLS certs (uncomment the 'TLS*' lines in the config),
there is no segfault.
The reproducer and the config can be found here:
URL1: http://jsynacek.fedorapeople.org/openldap/rebind-segfault/reproducer.c
URL2: http://jsynacek.fedorapeople.org/openldap/rebind-segfault/cn=config.ldif
11 years, 8 months
(ITS#7206) ldaprc: TLS_REQCERT demand does not terminate session, if a bad certicate comes from the server
by mkeller＠psi.de
Full_Name: Michael Keller
Version: 2.4.20
OS: SLES 11 SP1
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (95.131.98.154)
I have configured slapd to accept only TLS connections with:
security ssf=1 update_ssf=112 simple_bind=64
A ldapsearch -x returns correctly a
"# search result
search: 2
result: 13 Confidentiality required
text: confidentiality required"
When using TLS_REQCERT=demand a
ldapsearch -x -Z still returns results, even if a bad certificate comes from the
server. See debug output below.
ldapsearch -x -Z
ldap_start_tls: Connect error (-11)
additional info: TLS: hostname does not match CN in peer certificate
# extended LDIF
#
# LDAPv3
# base <dc=ee,dc=psi> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# ee.psi
dn: dc=ee,dc=psi
objectClass: dcObject
objectClass: organization
dc: ee
o: PSI-EE
# People, ee.psi
dn: ou=People,dc=ee,dc=psi
ou: People
objectClass: top
objectClass: organizationalUnit
# Group, ee.psi
dn: ou=Group,dc=ee,dc=psi
ou: Group
objectClass: top
objectClass: organizationalUnit
# search result
search: 3
result: 0 Success
# numResponses: 4
# numEntries: 3
Only when using "-ZZ" the connection isn't established. But the man page stated,
that the connection is terminated immediatly if a bad certificate is supplied
("ldap_start_tls returns with an error).
I think with "TLS_REQCERT demand" and a bad certificate the connection should be
terminated even if just a "-Z" is used. At the moment the behaviour is the same
for TLS_REQCERT = allow|try|demand
Debug output:
ldap_msgfree
TLS trace: SSL_connect:before/connect initialization
TLS trace: SSL_connect:SSLv2/v3 write client hello A
TLS trace: SSL_connect:SSLv3 read server hello A
TLS certificate verification: depth: 2, err: 0, subject:
/DC=psi/DC=ee/ST=Germany/O=PSI AG/OU=EE/CN=ee-caroot.ee.psi, issuer:
/DC=psi/DC=ee/ST=Germany/O=PSI AG/OU=EE/CN=ee-caroot.ee.psi
TLS certificate verification: depth: 1, err: 0, subject:
/DC=psi/DC=ee/ST=Germany/L=Aschaffenburg/O=PSI
AG/OU=EE/CN=EE-SigningCA@ldap-srv11, issuer: /DC=psi/DC=ee/ST=Germany/O=PSI
AG/OU=EE/CN=ee-caroot.ee.psi
TLS certificate verification: depth: 0, err: 0, subject:
/DC=psi/DC=ee/ST=Germany/L=Aschaffenburg/O=PSI AG/OU=EE/CN=ldap-srv11.ee.psi,
issuer: /DC=psi/DC=ee/ST=Germany/L=Aschaffenburg/O=PSI
AG/OU=EE/CN=EE-SigningCA@ldap-srv11
TLS trace: SSL_connect:SSLv3 read server certificate A
TLS trace: SSL_connect:SSLv3 read server certificate request A
TLS trace: SSL_connect:SSLv3 read server done A
TLS trace: SSL_connect:SSLv3 write client certificate A
TLS trace: SSL_connect:SSLv3 write client key exchange A
TLS trace: SSL_connect:SSLv3 write change cipher spec A
TLS trace: SSL_connect:SSLv3 write finished A
TLS trace: SSL_connect:SSLv3 flush data
TLS trace: SSL_connect:SSLv3 read finished A
TLS: hostname (ldap-srv11) does not match common name in certificate
(ldap-srv11.ee.psi).
ldap_err2string
ldap_start_tls: Connect error (-11)
additional info: TLS: hostname does not match CN in peer certificate
ldap_sasl_bind
ldap_send_initial_request
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({i) ber:
ber_flush2: 14 bytes to sd 3
ldap_result ld 0x615150 msgid 2
wait4msg ld 0x615150 msgid 2 (infinite timeout)
wait4msg continue ld 0x615150 msgid 2 all 1
** ld 0x615150 Connections:
* host: ldap-srv11 port: 389 (default)
refcnt: 2 status: Connected
last used: Wed Mar 14 08:49:55 2012
** ld 0x615150 Outstanding Requests:
* msgid 2, origid 2, status InProgress
outstanding referrals 0, parent count 0
ld 0x615150 request count 1 (abandoned 0)
** ld 0x615150 Response Queue:
Empty
ld 0x615150 response count 0
ldap_chkResponseList ld 0x615150 msgid 2 all 1
ldap_chkResponseList returns ld 0x615150 NULL
ldap_int_select
read1msg: ld 0x615150 msgid 2 all 1
ber_get_next
ber_get_next: tag 0x30 len 12 contents:
read1msg: ld 0x615150 msgid 2 message type bind
ber_scanf fmt ({eAA) ber:
read1msg: ld 0x615150 0 new referrals
read1msg: mark request completed, ld 0x615150 msgid 2
request done: ld 0x615150 msgid 2
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 2, msgid 2)
ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_scanf fmt (}) ber:
ldap_msgfree
ldap_search_ext
put_filter: "(objectclass=*)"
put_filter: simple
put_simple_filter: "objectclass=*"
ldap_send_initial_request
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({) ber:
ber_flush2: 51 bytes to sd 3
ldap_result ld 0x615150 msgid -1
wait4msg ld 0x615150 msgid -1 (infinite timeout)
wait4msg continue ld 0x615150 msgid -1 all 0
** ld 0x615150 Connections:
* host: ldap-srv11 port: 389 (default)
refcnt: 2 status: Connected
last used: Wed Mar 14 08:49:55 2012
** ld 0x615150 Outstanding Requests:
* msgid 3, origid 3, status InProgress
outstanding referrals 0, parent count 0
ld 0x615150 request count 1 (abandoned 0)
** ld 0x615150 Response Queue:
Empty
ld 0x615150 response count 0
ldap_chkResponseList ld 0x615150 msgid -1 all 0
ldap_chkResponseList returns ld 0x615150 NULL
ldap_int_select
read1msg: ld 0x615150 msgid -1 all 0
ber_get_next
ber_get_next: tag 0x30 len 89 contents:
read1msg: ld 0x615150 msgid 3 message type search-entry
ldap_get_dn_ber
ber_scanf fmt ({ml{) ber:
ldap_dn2ufn
ldap_dn_normalize
ber_scanf fmt ({xx) ber:
ldap_get_attribute_ber
ber_scanf fmt ({mM}) ber:
ldap_get_attribute_ber
ber_scanf fmt ({mM}) ber:
ldap_get_attribute_ber
ber_scanf fmt ({mM}) ber:
ldap_get_attribute_ber
ldap_msgfree
ldap_result ld 0x615150 msgid -1
wait4msg ld 0x615150 msgid -1 (infinite timeout)
wait4msg continue ld 0x615150 msgid -1 all 0
** ld 0x615150 Connections:
* host: ldap-srv11 port: 389 (default)
refcnt: 2 status: Connected
last used: Wed Mar 14 08:49:55 2012
** ld 0x615150 Outstanding Requests:
* msgid 3, origid 3, status InProgress
outstanding referrals 0, parent count 0
ld 0x615150 request count 1 (abandoned 0)
** ld 0x615150 Response Queue:
Empty
ld 0x615150 response count 0
ldap_chkResponseList ld 0x615150 msgid -1 all 0
ldap_chkResponseList returns ld 0x615150 NULL
ldap_int_select
read1msg: ld 0x615150 msgid -1 all 0
ber_get_next
ber_get_next: tag 0x30 len 89 contents:
read1msg: ld 0x615150 msgid 3 message type search-entry
ldap_get_dn_ber
ber_scanf fmt ({ml{) ber:
ldap_dn2ufn
ldap_dn_normalize
ber_scanf fmt ({xx) ber:
ldap_get_attribute_ber
ber_scanf fmt ({mM}) ber:
ldap_get_attribute_ber
ber_scanf fmt ({mM}) ber:
ldap_get_attribute_ber
ldap_msgfree
ldap_result ld 0x615150 msgid -1
wait4msg ld 0x615150 msgid -1 (infinite timeout)
wait4msg continue ld 0x615150 msgid -1 all 0
** ld 0x615150 Connections:
* host: ldap-srv11 port: 389 (default)
refcnt: 2 status: Connected
last used: Wed Mar 14 08:49:55 2012
** ld 0x615150 Outstanding Requests:
* msgid 3, origid 3, status InProgress
outstanding referrals 0, parent count 0
ld 0x615150 request count 1 (abandoned 0)
** ld 0x615150 Response Queue:
Empty
ld 0x615150 response count 0
ldap_chkResponseList ld 0x615150 msgid -1 all 0
ldap_chkResponseList returns ld 0x615150 NULL
ldap_int_select
read1msg: ld 0x615150 msgid -1 all 0
ber_get_next
ber_get_next: tag 0x30 len 87 contents:
read1msg: ld 0x615150 msgid 3 message type search-entry
ldap_get_dn_ber
ber_scanf fmt ({ml{) ber:
ldap_dn2ufn
ldap_dn_normalize
ber_scanf fmt ({xx) ber:
ldap_get_attribute_ber
ber_scanf fmt ({mM}) ber:
ldap_get_attribute_ber
ber_scanf fmt ({mM}) ber:
ldap_get_attribute_ber
ldap_msgfree
ldap_result ld 0x615150 msgid -1
wait4msg ld 0x615150 msgid -1 (infinite timeout)
wait4msg continue ld 0x615150 msgid -1 all 0
** ld 0x615150 Connections:
* host: ldap-srv11 port: 389 (default)
refcnt: 2 status: Connected
last used: Wed Mar 14 08:49:55 2012
** ld 0x615150 Outstanding Requests:
* msgid 3, origid 3, status InProgress
outstanding referrals 0, parent count 0
ld 0x615150 request count 1 (abandoned 0)
** ld 0x615150 Response Queue:
Empty
ld 0x615150 response count 0
ldap_chkResponseList ld 0x615150 msgid -1 all 0
ldap_chkResponseList returns ld 0x615150 NULL
ldap_int_select
read1msg: ld 0x615150 msgid -1 all 0
ber_get_next
ber_get_next: tag 0x30 len 12 contents:
read1msg: ld 0x615150 msgid 3 message type search-result
ber_scanf fmt ({eAA) ber:
read1msg: ld 0x615150 0 new referrals
read1msg: mark request completed, ld 0x615150 msgid 3
request done: ld 0x615150 msgid 3
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 3, msgid 3)
ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_scanf fmt (}) ber:
ldap_err2string
ldap_msgfree
ldap_free_connection 1 1
ldap_send_unbind
ber_flush2: 7 bytes to sd 3
TLS trace: SSL3 alert write:warning:close notify
ldap_free_connection: actually freed
11 years, 8 months
