jeff(a)jeffrodriguez.com wrote:
> Full_Name: Jeff Rodriguez
> Version: 2.3.30
> OS: Debian etch
> URL: ftp://ftp.openldap.org/incoming/jeff-rodriguez-080520.tgz
> Submission from: (NULL) (208.48.140.97)
>
>
> syncprov seems to be causing a segfault when importing kerberos entries.
>
> slapd.conf, LDIFs, heimdal kerberos schema, and logs included. These are live
> files I was used to generate the segfault. It's also reproducible with the conf
> and ldif files customized to the environment. Commenting out syncprov and
> related lines in the conf eliminates the segfault.
>
> 1. stop slapd
> 2. wipe out current database
> 3. slapadd schema.ldif and chown the database to openldap user and group
> 4. start slapd with: /usr/sbin/slapd -g openldap -u openldap -d 1 -h "ldap:///
> ldapi:///"
> 5. add ldif entries live: ldapadd -H ldapi:///var/run/ldapi -D
> cn=admin,o=example -w CHANGE_THIS_PASSWORD -f bugged.ldif
> 6. segfault
>
> uname -a:
> Linux ds1.phx2 2.6.18-6-xen-amd64 #1 SMP Sun Feb 10 18:02:52 UTC 2008 x86_64
> GNU/Linux
Your slapd.conf is incorrect. Please re-read the slapo-syncprov(5) manpage;
syncprov must be instantiated over a specific database. You have it configured
in the global section, not on a specific database. This ITS will be closed.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Lea Anthony wrote:
> The version I have does not have debugging info, however I was able to get hold of this backtrace:
>
>
> #0 0xb7b5bb05 in free () from /lib/libc.so.6
> #1 0xb7ac566e in _sasldb_getdata () from /usr/lib/sasl2/libsasldb.so.2
> #2 0xb7ac33d7 in sasldb_auxprop_lookup () from /usr/lib/sasl2/libsasldb.so.2
> #3 0xb7e2df6e in _sasl_auxprop_lookup () from /usr/lib/libsasl2.so.2
> #4 0xb7e2f6b4 in _sasl_canon_user () from /usr/lib/libsasl2.so.2
> #5 0xb7ac8425 in login_server_mech_step () from /usr/lib/sasl2/liblogin.so.2
> #6 0xb7e38567 in sasl_server_step () from /usr/lib/libsasl2.so.2
> #7 0x080a5c08 in ?? ()
> #8 0x08213c10 in ?? ()
> #9 0x082289fd in ?? ()
> #10 0x00000000 in ?? ()
>
> Looks like the bug is in libsasl2 ?
It seems so.
> ----- Original Message -----
> From: "Howard Chu"<hyc(a)symas.com>
> To: "lea anthony"<lea.anthony(a)meirion-dwyfor.ac.uk>
> Cc: openldap-its(a)openldap.org
> Sent: Tuesday, June 17, 2008 9:22:43 PM (GMT) Europe/London
> Subject: Re: (ITS#5561) SEGV using TLS/SASL
>
> lea.anthony(a)meirion-dwyfor.ac.uk wrote:
>> Full_Name: Lea Anthony
>> Version: 2.3.40
>> OS: Arch Linux
>> URL: http://pastebin.com/f6b680f22
>> Submission from: (NULL) (194.82.229.100)
>>
>>
>> I have TLS setup as follows:
>>
>> TLSCertificateFile /etc/openldap/certs/cert.pem
>> TLSCertificateKeyFile /etc/openldap/certs/key.pem
>> TLSCipherSuite HIGH:MEDIUM:+TLSv1:+SSLv2:+SSLv3
>>
>> The server starts fine and doing "ldapsearch -x -ZZ" will do an anonymous bind
>> fine.
>>
>> However, doing "ldapsearch -ZZ" will cause a segfault on the server. The
>> pastebin URL contains the post SSL negotiation debug lines from "slapd -d -1".
>
> I'm unable to reproduce this crash. Please provide a stack trace.
>
> http://www.openldap.org/faq/data/cache/59.html
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
dev-zero(a)gentoo.org wrote:
> Full_Name: Tiziano Müller
> Version: 2.4.10
> OS: Gentoo Linux 2008.0
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (212.126.163.234)
>
>
> I've generated certificates for the server and a client using my own CA.
> The following works:
> * client checks server certificate
> * server checks client certificate
>
> Nevertheless the following keeped appearing in the log:
> 2008-06-18T13:49:13.135510+02:00 localhost slapd[1771]: connection_read(14):
> unable to get TLS client DN, error=-4 id=1
>
> And I was therefore not able to use SASL/EXTERNAL.
>
> When I rebuilt OpenLDAP with OpenSSL instead of GnuTLS it suddenly worked (while
> not changing anything else).
>
> The certificates have been generated using OpenSSL (even though this shouldn't
> matter).
Works fine for me. Most likely your GnuTLS is broken. See ITS#5515. This ITS
will be closed.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
fkhan(a)emergen.biz wrote:
> Full_Name: Faraz Khan
> Version: 2.4.7
> OS: Linux Debian Etch
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (202.133.78.60)
>
>
> Documentation update: OpenLdap 2.4 allows the use of the ADD and Zap ACLs (in
> addition to write) to finely control whether an ADD or a Zap is allowed. Write =
> Add + Zap
>
> This is not documented anywhere- was told to me by Pierangelo Masarati
Now it's documented in the man page in HEAD, see
<http://www.openldap.org/devel/cvsweb.cgi/doc/man/man5/slapd.access.5>
for details. Please check.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: ando(a)sys-net.it
-----------------------------------
Full_Name: Tiziano Müller
Version: 2.4.10
OS: Gentoo Linux 2008.0
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (212.126.163.234)
I've generated certificates for the server and a client using my own CA.
The following works:
* client checks server certificate
* server checks client certificate
Nevertheless the following keeped appearing in the log:
2008-06-18T13:49:13.135510+02:00 localhost slapd[1771]: connection_read(14):
unable to get TLS client DN, error=-4 id=1
And I was therefore not able to use SASL/EXTERNAL.
When I rebuilt OpenLDAP with OpenSSL instead of GnuTLS it suddenly worked (while
not changing anything else).
The certificates have been generated using OpenSSL (even though this shouldn't
matter).
Full_Name: Faraz Khan
Version: 2.4.7
OS: Linux Debian Etch
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (202.133.78.60)
Documentation update: OpenLdap 2.4 allows the use of the ADD and Zap ACLs (in
addition to write) to finely control whether an ADD or a Zap is allowed. Write =
Add + Zap
This is not documented anywhere- was told to me by Pierangelo Masarati
jwm(a)horde.net wrote:
> Full_Name: John Morrissey
> Version: RE23-20080612
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (2001:4830:120d:0:21f:5bff:fee9:da92)
>
>
> The fix for ITS 5469 stopped the assertion failures that caused slapd to crash,
> but slapd continues to crash every few days due to receipt of SIGPIPEs.
That is not possible; slapd explicitly ignores SIGPIPE.
> We had
> been running 2.3.41 plus the fix for ITS 5469, but upgraded to RE23 as of about
> a week ago to make sure a fix wasn't already present. Below is a representative
> backtrace.
This trace is not indicative of a crash. You have to tell gdb not to stop when
SIGPIPE is received in order to get an accurate view of the program behavior:
"handle SIGPIPE nostop"
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
lea.anthony(a)meirion-dwyfor.ac.uk wrote:
> Full_Name: Lea Anthony
> Version: 2.3.40
> OS: Arch Linux
> URL: http://pastebin.com/f6b680f22
> Submission from: (NULL) (194.82.229.100)
>
>
> I have TLS setup as follows:
>
> TLSCertificateFile /etc/openldap/certs/cert.pem
> TLSCertificateKeyFile /etc/openldap/certs/key.pem
> TLSCipherSuite HIGH:MEDIUM:+TLSv1:+SSLv2:+SSLv3
>
> The server starts fine and doing "ldapsearch -x -ZZ" will do an anonymous bind
> fine.
>
> However, doing "ldapsearch -ZZ" will cause a segfault on the server. The
> pastebin URL contains the post SSL negotiation debug lines from "slapd -d -1".
I'm unable to reproduce this crash. Please provide a stack trace.
http://www.openldap.org/faq/data/cache/59.html
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
rein(a)OpenLDAP.org wrote:
> This message is in MIME format. The first part should be readable text,
> while the remaining parts are likely unreadable without MIME-aware tools.
>
> --8323329-1817437300-1213728437=:15378
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
>
> On Mon, 16 Jun 2008, rein(a)OpenLDAP.org wrote:
>
> rein(a)OpenLDAP.org wrote:
>
>> A fix that seems to solve this is that syncprov_findbase(FIND_CSN)
>> should search for entries whose entryCSN value is less than the
>> largest contextCSN presented by the client. All the test scripts
>> succeed if I try this, but I'm not convinced that this is the correct
>> fix. Would it not be more correct to ignore the entire CSN set
>> presented by the consumer when it has been determined as stale.
>
> After looking a bit more on this I'm more convinced that the alternative
> fix is the correct. A patch that implements this is attached, all tests
> succeed with it. Howard, can you approve or comment on it?
This patch looks OK to me, go ahead and commit.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/