(ITS#6810) slapd crashes writing to bdb backend
by bruno_haleblian＠carrefour.com
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 }
12 years, 7 months
Re: (ITS#6807) syncrepl sends incomplete sync cookie in MMR
by hyc＠symas.com
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/
12 years, 7 months
Re: (ITS#6791) Patch - Mozilla NSS - cert verify uses incorrect values
by hyc＠symas.com
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-incorrec...
> 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/
12 years, 7 months
(ITS#6807) syncrepl sends incomplete sync cookie in MMR
by hyc＠OpenLDAP.org
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.
12 years, 7 months
Re: (ITS#6684) Patch for autogroup overlay
by moenoel＠informatik.uni-bremen.de
> 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-autogro...
Regards,
Christian Manal
12 years, 7 months
(ITS#6806) Invalid ldapadd crashes openldap with ndb backend
by anderson＠vailsys.com
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)
12 years, 7 months
Re: ITS#6805
by Kurt＠OpenLDAP.org
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.
12 years, 7 months
Re: ITS#6805
by michael＠stroeder.com
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.
12 years, 7 months
