openldap-bugs January 2011

openldap-bugs@openldap.org

36 participants
177 discussions

(ITS#6810) slapd crashes writing to bdb backend
by bruno_haleblian＠carrefour.com 28 Jan '11

28 Jan '11

Full_Name: Bruno HALEBLIAN Version: 2.4.23 OS: RHEL 5.5/64 bits URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.243.12.111) Hello, I'm stuck with "random" slapd crashes, my slapd has been tested successfully in read mode but since I run updates, I get several crashes a day, with no BDB corruption (recover and restart OK) but I can't let this go to production stage. Here's the first core stack I caught, I'll send more if I meet different ones. Thanks for your help. kernel: slapd[13284]: segfault at 0000000000000008 rip 000000000052a377 rsp 0000000043fa5160 error 4 Program terminated with signal 11, Segmentation fault. #0 0x000000000052a377 in syncprov_matchops (op=0x182cdb00, opc=0x182d04c8, saveit=1) at syncprov.c:1309 1309 op2.ors_filter = ss->s_op->ors_filter->f_and->f_next; (gdb) where #0 0x000000000052a377 in syncprov_matchops (op=0x182cdb00, opc=0x182d04c8, saveit=1) at syncprov.c:1309 #1 0x000000000052a5e1 in syncprov_op_mod (op=0x182cdb00, rs=<value optimized out>) at syncprov.c:2075 #2 0x000000000049757a in overlay_op_walk (op=0x182cdb00, rs=0x43fa6c70, which=op_modify, oi=0x17b6e2f0, on=0x17b6e4d0) at backover.c:659 #3 0x0000000000497b47 in over_op_func (op=0x182cdb00, rs=0x43fa6c70, which=op_modify) at backover.c:721 #4 0x000000000044c537 in fe_op_modify (op=0x182cdb00, rs=0x43fa6c70) at modify.c:301 #5 0x000000000044cc92 in do_modify (op=0x182cdb00, rs=0x43fa6c70) at modify.c:175 #6 0x0000000000435655 in connection_operation (ctx=0x43fa6dc0, arg_v=<value optimized out>) at connection.c:1109 #7 0x0000000000435c2f in connection_read_thread (ctx=0x43fa6dc0, argv=<value optimized out>) at connection.c:1245 #8 0x000000000054345c in ldap_int_thread_pool_wrapper (xpool=0x17af0350) at tpool.c:685 #9 0x000000339360673d in start_thread () from /lib64/libpthread.so.0 #10 0x0000003392ed3d1d in removexattr () from /lib64/libc.so.6 #11 0x0000000000000000 in ?? () (gdb) list *0x000000000052a377 0x52a377 is in syncprov_matchops (syncprov.c:1309). 1304 ldap_pvt_thread_mutex_lock( &ss->s_mutex ); 1305 if (ss->s_flags & PS_FIX_FILTER) { 1306 /* Skip the AND/GE clause that we stuck on in front. We 1307 would lose deletes/mods that happen during the refresh 1308 phase otherwise (ITS#6555) */ 1309 op2.ors_filter = ss->s_op->ors_filter->f_and->f_next; 1310 } 1311 ldap_pvt_thread_mutex_unlock( &ss->s_mutex ); 1312 rc = test_filter( &op2, e, op2.ors_filter ); 1313 }

1 0

(ITS#6809) back-sock compare is missing a newline
by hyc＠OpenLDAP.org 28 Jan '11

28 Jan '11

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc All of the messages from back-sock to the other socket server are supposed to be terminated by two newlines. The Compare operation only has one.

1 0

Re: (ITS#6807) syncrepl sends incomplete sync cookie in MMR
by hyc＠symas.com 28 Jan '11

28 Jan '11

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: HEAD/RE24 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.94.188.8) > Submitted by: hyc > > > In syncrepl_updateCookie() the cookie received from the provider is dup'd as-is. > If the provider is stopped and restarted, this same cookie will be sent back on > the next refresh attempt. In refreshAndPersist mode the cookies sent from the > provider will only contain a single CSN; CSNs from other MMR servers are > omitted. During a restart, because the consumer sends a cookie with only one > CSN, the provider will consider the consumer out of date. > > A fix is coming shortly. For the record... I spent some time considering whether this should actually be fixed in the provider or the consumer. I decided on fixing in the consumer for the sake of network bandwidth/efficiency - in persist mode, a cookie may be sent with every single write operation. Generally only one CSN will be relevant for any given write op, so it would be a waste to send all of the other unchanged CSNs every time. On the consumer side, the consumer must always send all of the context info it has available. This might involve more volume in a request but ordinarily the actual consumer request is only a tiny fraction of the total network traffic. Purists might say that this goes against RFC4533 which states that consumers should treat sync cookies as opaque items, but the OpenLDAP implementation has always relied on exact knowledge of the sync cookie format; this was always required in order to support cascaded replication if nothing else. Also this ITS is specific to MMR, which is not addressed at all in RFC4533. -- -- 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#6808) pcache monitoring cleanup needs monitor entry DN
by masarati＠aero.polimi.it 27 Jan '11

27 Jan '11

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2.40.14.92) Submitted by: ando A fix is coming. p.

1 0

Re: (ITS#6791) Patch - Mozilla NSS - cert verify uses incorrect values
by hyc＠symas.com 27 Jan '11

27 Jan '11

rmeggins(a)redhat.com wrote: > Full_Name: Rich Megginson > Version: 2.4.23 (current CVS HEAD) > OS: RHEL6 > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-cert-verify-uses-incorrect-… > Submission from: (NULL) (76.113.111.209) > > > The cert verify routines were using type SECCertUsage instead of type > SECCertificateUsage. The values are similar, and this was causing verify errors > of SEC_ERROR_INADEQUATE_KEY_USAGE and SEC_ERROR_INADEQUATE_CERT_TYPE. MozNSS > only checks the usage if the cert includes the usage extensions which is why I > didn't see this error earlier. Talk about confusing ... committed to HEAD, thanks. > > These patch files are derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by Red Hat. Red Hat has not assigned rights > and/or interest in this work to any party. I, Rich Megginson am > authorized by Red Hat, my employer, to release this work under the > following terms. > > Red Hat hereby place the following modifications to OpenLDAP Software > (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose > with or without attribution and/or other notice. > -- -- 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#6807) syncrepl sends incomplete sync cookie in MMR
by hyc＠OpenLDAP.org 27 Jan '11

27 Jan '11

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc In syncrepl_updateCookie() the cookie received from the provider is dup'd as-is. If the provider is stopped and restarted, this same cookie will be sent back on the next refresh attempt. In refreshAndPersist mode the cookies sent from the provider will only contain a single CSN; CSNs from other MMR servers are omitted. During a restart, because the consumer sends a cookie with only one CSN, the provider will consider the consumer out of date. A fix is coming shortly.

1 0

Re: (ITS#6684) Patch for autogroup overlay
by moenoel＠informatik.uni-bremen.de 27 Jan '11

27 Jan '11

> 1) it should simply be comparing the AttributeDescription pointers > 2) since the "memberof" attribute is actually configurable in the memberof > overlay, there's no guarantee that this is the correct attribute to be looking > for. It should also be configurable in your patch. > > You're using strcasecmp, but your inputs are already normalized values. You > should just use ber_bvcmp. > Since I am also interested in this, I took some time to make a new patch. I took Norberts original patch, applied it to a current checkout from HEAD and tried to fix the issues mentioned by Howard. My initial tests are looking good. My C skills are rather mediocre, though, so I hope I didn't slaughter the thing :-) http://www.informatik.uni-bremen.de/~moenoel/ldap/christian-manal-autogroup… Regards, Christian Manal

1 0

(ITS#6806) Invalid ldapadd crashes openldap with ndb backend
by anderson＠vailsys.com 27 Jan '11

27 Jan '11

Full_Name: Nathanael Anderson Version: 2.4.19 OS: RHEL 6 (Linux) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.63.156.11) #00_die.ldif dn: cn=die,ou=groups,dc=domain,dc=com objectclass: groupofnames cn: Operations description: People in Operations ldapadd -x -D "cn=admin,dc=domain,dc=com" -W -f 00_die.ldif This will crash the openldap server every time with a Bus error message conn=0 op=1 ADD dn="cn=die,ou=groups,dc=domain,dc=com" Entry (cn=die,ou=groups,dc=domain,dc=com): object class 'groupOfNames' requires attribute 'member' conn=0 op=1 RESULT tag=105 err=65 text=object class 'groupOfNames' requires attribute 'member' Bus error (core dumped)

1 0

Re: ITS#6805
by Kurt＠OpenLDAP.org 27 Jan '11

27 Jan '11

On Jan 27, 2011, at 2:30 AM, Michael Str=F6der wrote: > Kurt(a)OpenLDAP.org wrote: >> The OP expects somehow for the server to prevent the client from =3D >> exposing information when the server has no control over what the = client =3D >> sends. This simply is not possible and hence should not be expected. >>=20 >> Even if the server were configured only with a ldaps:// listener, =3D >> clients would not be precluded from sending a password to the server = in =3D >> the clear. A client could be told to connect to that listener and = send =3D >> a LDAP Simple Bind with password without ever attempting to start = TLS. =3D >> Sure, the server will error, but the password is exposed none the = less. >=20 > While this is true in general there still could be a benefit from = disallowing > connections without StartTLS at the server-side: Yes, and slapd(8) has long supported such a configuration and, in fact, = the OP had such a configuration. > Normally in a serious deployment there are integration tests done with = client > applications for which no real passwords are used. Disallowing = non-protected > connections would reveal misconfiguration immediately and the = application can > then be modified to do the right thing. >=20 > Ciao, Michael.

1 0

Re: ITS#6805
by michael＠stroeder.com 27 Jan '11

27 Jan '11

Kurt(a)OpenLDAP.org wrote: > The OP expects somehow for the server to prevent the client from = > exposing information when the server has no control over what the client = > sends. This simply is not possible and hence should not be expected. > > Even if the server were configured only with a ldaps:// listener, = > clients would not be precluded from sending a password to the server in = > the clear. A client could be told to connect to that listener and send = > a LDAP Simple Bind with password without ever attempting to start TLS. = > Sure, the server will error, but the password is exposed none the less. While this is true in general there still could be a benefit from disallowing connections without StartTLS at the server-side: Normally in a serious deployment there are integration tests done with client applications for which no real passwords are used. Disallowing non-protected connections would reveal misconfiguration immediately and the application can then be modified to do the right thing. Ciao, Michael.

1 0

← Newer
1
2
3
4
5
6
7
...
18
Older →

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 January 2011