Re: (ITS#6572) slapd crash caused by refint's cn=config modification
by mbackes＠symas.com
> Here's a patch that fixes 6572.
Heh, okay Quanah.
This patch file is derived from OpenLDAP Software. All of the =
modifications to OpenLDAP Software represented in the previous patch was =
developed by me for Symas and the OpenLDAP project. I am authorized by =
Symas, my employer, to release this work under the following terms.
Portions Copyright 2010 Symas Corporation.
Redistribution and use in source and binary forms, with or without =
modification, are permitted only as authorized by the OpenLDAP Public =
License.
Matthew Backes
Symas Corporation
mbackes(a)symas.com
13 years, 3 months
Re: (ITS#6572) slapd crash caused by refint's cn=config modification
by mbackes＠symas.com
--Apple-Mail-322--405209956
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=us-ascii
Here's a patch that fixes 6572.
* Switch to use BER_BVISNULL, BER_BVZERO, and ch_free instead
* Clean up Ozone's "breadcrumbs" while we're at it (unrelated but trivial)
* Should apply cleanly to RE24 and HEAD
* Older dyn-config refints (RE22, RE23) likely have the same problem
Matthew Backes
Symas Corporation
mbackes(a)symas.com
--Apple-Mail-322--405209956
Content-Disposition: attachment;
filename=refint-patch-its-6572.txt
Content-Type: text/plain;
name="refint-patch-its-6572.txt"
Content-Transfer-Encoding: 7bit
Index: refint.c
===================================================================
RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays/refint.c,v
retrieving revision 1.46
diff -u -r1.46 refint.c
--- refint.c 13 Apr 2010 20:18:25 -0000 1.46
+++ refint.c 13 Jun 2010 04:02:09 -0000
@@ -76,7 +76,6 @@
} refint_q;
typedef struct refint_data_s {
- const char *message; /* breadcrumbs */
struct refint_attrs_s *attrs; /* list of known attrs */
BerValue dn; /* basedn in parent, */
BerValue nothing; /* the nothing value, if needed */
@@ -210,21 +209,17 @@
rc = 0;
break;
case REFINT_NOTHING:
- if ( dd->nothing.bv_val )
- ber_memfree ( dd->nothing.bv_val );
- if ( dd->nnothing.bv_val )
- ber_memfree ( dd->nnothing.bv_val );
- dd->nothing.bv_len = 0;
- dd->nnothing.bv_len = 0;
+ ch_free( dd->nothing.bv_val );
+ ch_free( dd->nnothing.bv_val );
+ BER_BVZERO( &dd->nothing );
+ BER_BVZERO( &dd->nnothing );
rc = 0;
break;
case REFINT_MODIFIERSNAME:
- if ( dd->refint_dn.bv_val )
- ber_memfree ( dd->refint_dn.bv_val );
- if ( dd->refint_ndn.bv_val )
- ber_memfree ( dd->refint_ndn.bv_val );
- dd->refint_dn.bv_len = 0;
- dd->refint_ndn.bv_len = 0;
+ ch_free( dd->refint_dn.bv_val );
+ ch_free( dd->refint_ndn.bv_val );
+ BER_BVZERO( &dd->refint_dn );
+ BER_BVZERO( &dd->refint_ndn );
rc = 0;
break;
default:
@@ -256,22 +251,26 @@
}
break;
case REFINT_NOTHING:
- if ( dd->nothing.bv_val )
- ber_memfree ( dd->nothing.bv_val );
- if ( dd->nnothing.bv_val )
- ber_memfree ( dd->nnothing.bv_val );
- dd->nothing = c->value_dn;
- dd->nnothing = c->value_ndn;
- rc = 0;
+ if ( !BER_BVISNULL( &c->value_ndn )) {
+ ch_free ( dd->nothing.bv_val );
+ ch_free ( dd->nnothing.bv_val );
+ dd->nothing = c->value_dn;
+ dd->nnothing = c->value_ndn;
+ rc = 0;
+ } else {
+ rc = ARG_BAD_CONF;
+ }
break;
case REFINT_MODIFIERSNAME:
- if ( dd->refint_dn.bv_val )
- ber_memfree ( dd->refint_dn.bv_val );
- if ( dd->refint_ndn.bv_val )
- ber_memfree ( dd->refint_ndn.bv_val );
- dd->refint_dn = c->value_dn;
- dd->refint_ndn = c->value_ndn;
- rc = 0;
+ if ( !BER_BVISNULL( &c->value_ndn )) {
+ ch_free( &dd->refint_dn.bv_val );
+ ch_free( &dd->refint_ndn.bv_val );
+ dd->refint_dn = c->value_dn;
+ dd->refint_ndn = c->value_ndn;
+ rc = 0;
+ } else {
+ rc = ARG_BAD_CONF;
+ }
break;
default:
abort ();
@@ -299,7 +298,6 @@
slap_overinst *on = (slap_overinst *)be->bd_info;
refint_data *id = ch_calloc(1,sizeof(refint_data));
- id->message = "_init";
on->on_bi.bi_private = id;
ldap_pvt_thread_mutex_init( &id->qmutex );
return(0);
@@ -335,7 +333,6 @@
{
slap_overinst *on = (slap_overinst *)be->bd_info;
refint_data *id = on->on_bi.bi_private;
- id->message = "_open";
if ( BER_BVISNULL( &id->dn )) {
if ( BER_BVISNULL( &be->be_nsuffix[0] ))
@@ -354,7 +351,6 @@
** foreach configured attribute:
** free it;
** free our basedn;
-** (do not) free id->message;
** reset on_bi.bi_private;
** free our config data;
**
@@ -369,7 +365,6 @@
slap_overinst *on = (slap_overinst *) be->bd_info;
refint_data *id = on->on_bi.bi_private;
refint_attrs *ii, *ij;
- id->message = "_close";
for(ii = id->attrs; ii; ii = ij) {
ij = ii->next;
@@ -870,8 +865,6 @@
BackendDB *db = NULL;
refint_attrs *ip;
- id->message = "_refint_response";
-
/* If the main op failed or is not a Delete or ModRdn, ignore it */
if (( op->o_tag != LDAP_REQ_DELETE && op->o_tag != LDAP_REQ_MODRDN ) ||
rs->sr_err != LDAP_SUCCESS )
--Apple-Mail-322--405209956--
13 years, 3 months
(ITS#6572)
by daniel＠pluta.biz
short add-on note:
any kind of modify operation on this attribute seems to crash slapd
13 years, 3 months
Re: (ITS#6573) schema errors
by Kurt＠OpenLDAP.org
On Jun 6, 2010, at 8:27 PM, peychart(a)mail.pf wrote:
> Full_Name: Philippe EYCHART
> Version: last
> OS: linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (203.185.181.157)
>=20
>=20
> Hi,
>=20
> 1/- It seems there is one schema definition error : the "street" =
attribute is
> defined twice in the "domain" objectClass (cosine.schema) ...
> So, the LDAP database repeat this error ; see: ldapsearch -x -b =
"cn=3Dsubschema"
> -s base objectclasses
As far as the old RFC 1274 version of 'domain', cosine.schema is =
correct. (It's not an error to list attributes multiple times in schema =
descriptions. There's a number of multiple listings found in RFC =
specifications of object classes.) =20
Of course, all of cosine.schema should be replaced with a new file =
derived directly from RFC 4524 with non-conflicting deprecated stuff at =
the end of the file or moved to cosine-old.schema file.
>=20
> 2/- the attribute "internationaliSDNNumber" is defined with a "i" for =
"iSDN" but
> with a "I" in the "domain" objectClass definition ... (so, a compare =
with no
> sensitive case option must be done to find it ...)
Names are case insensitive.
>=20
> (cf.: <http://home.gna.org/ldapcppei/Frontends/Howto-5.fr.html#S5>)
> Regards,
> Philippe EYCHART
>=20
13 years, 3 months
(ITS#6573) schema errors
by peychart＠mail.pf
Full_Name: Philippe EYCHART
Version: last
OS: linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (203.185.181.157)
Hi,
1/- It seems there is one schema definition error : the "street" attribute is
defined twice in the "domain" objectClass (cosine.schema) ...
So, the LDAP database repeat this error ; see: ldapsearch -x -b "cn=subschema"
-s base objectclasses
2/- the attribute "internationaliSDNNumber" is defined with a "i" for "iSDN" but
with a "I" in the "domain" objectClass definition ... (so, a compare with no
sensitive case option must be done to find it ...)
(cf.: <http://home.gna.org/ldapcppei/Frontends/Howto-5.fr.html#S5>)
Regards,
Philippe EYCHART
13 years, 3 months
(ITS#6572) slapd crash caused by refint's cn=config modification
by daniel＠pluta.biz
Full_Name: Daniel Pluta
Version: 2.4.21
OS: Lnx
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (2001:470:9feb:ff02:6834:fd61:37f:67da)
Hi,
after a silly typo (removed the "," rdn-separator character) in refint's
cn=config settings while modifying "olcRefintNothing" attribute the attribute
contained the following escaped value:
olcRefintNothing: cn=refintcn\3Dconfig
Using ldapmodify with cn=config to correct this value back into e.g.
"cn=refint,cn=config" caused slapd to crash.
Re-starting slapd (recovering db files...) worked fine but the value of course
is still the "ugly" one above. Trying to correct (using ldapmodify) this value
once more caused slapd to crash again.
Cheers
Daniel
13 years, 3 months
Re: (ITS#6556) test031 core dumps after applying first filter
by dieter＠dkluenter.de
Hi,
I have run slapd in valgrind now, which produced following error:
==15353== 1 errors in context 1 of 5:
==15353== Invalid write of size 4
==15353== at 0x80E64B5: slap_sl_free (sl_malloc.c:492)
==15353== by 0x80A0EEA: ch_free (ch_malloc.c:137)
==15353== by 0x80E3DC9: mra_free (mra.c:43)
==15353== by 0x80855B0: filter_free_x (filter.c:556)
==15353== by 0x80836CD: do_search (search.c:230)
==15353== by 0x8080588: connection_operation (connection.c:1109)
==15353== by 0x403B376: ldap_int_thread_pool_wrapper (tpool.c:685)
==15353== by 0x43046E4: start_thread (in /lib/libpthread-2.10.1.so)
==15353== by 0x43045FF: ??? (in /lib/libpthread-2.10.1.so)
==15353== Address 0x843692b1 is not stack'd, malloc'd or (recently)
free'd
Full valgrind log can be found at
http://pastebin.de/6914
-Dieter
13 years, 3 months
(ITS#6571) rebind-as-user only works on first connection attempt
by maci＠satgnu.net
Full_Name: Marcel Wysocki
Version: 2.4.22
OS: Solaris/Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (88.79.126.162)
Hello,
i have the same problem as described here:
http://www.openldap.org/lists/openldap-software/200712/msg00283.html
here are some logs:
@(#) $OpenLDAP: slapd 2.4.22 (Jun 4 2010 11:56:46) $
slapd starting
Initial connection:
##########################
conn=1000 fd=11 ACCEPT from IP=127.0.0.1:45654 (IP=0.0.0.0:389)
conn=1000 op=0 BIND dn="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz"
method=128
conn=1000 op=0 BIND dn="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz"
mech=SIMPLE ssf=0
conn=1000 op=0 RESULT tag=97 err=0 text=
##########################
First ldapsearch:
##########################
conn=1000 op=2 SRCH base="ou=users,ou=BAR,c=de,o=bazbaz" scope=1 deref=3
filter="(mobile=491721000227)"
conn=1000 op=2 SRCH attr=objectclass
conn=1000 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=
##########################
backend server has been restarted, sencond ldapsearch:
##########################
conn=1000 op=3 SRCH base="ou=users,ou=BAR,c=de,o=bazbaz" scope=1 deref=3
filter="(mobile=491721000227)"
conn=1000 op=3 SRCH attr=objectclass
conn=1000 op=3 ldap_back_retry: retrying URI="ldap://10.2.163.13:389"
DN="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz"
conn=1000 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text=
##########################
backend server has been stopped, third ldapsearch, fails as it should:
##########################
conn=1000 op=4 SRCH base="ou=users,ou=BAR,c=de,o=bazbaz" scope=1 deref=3
filter="(mobile=491721000227)"
conn=1000 op=4 SRCH attr=objectclass
conn=1000 op=4 ldap_back_retry: retrying URI="ldap://10.2.163.13:389"
DN="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz"
conn=1000 op=4 SEARCH RESULT tag=101 err=52 nentries=0 text=
##########################
backend server has been restarted, fourth ldapsearch, rebind fails:
##########################
conn=1000 op=5 SRCH base="ou=users,ou=BAR,c=de,o=bazbaz" scope=1 deref=3
filter="(mobile=491721000227)"
conn=1000 op=5 SRCH attr=objectclass
conn=1000 op=5 ldap_back_dobind_int:
DN="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz" without creds,
binding anonymously
conn=1000 op=5 SEARCH RESULT tag=101 err=0 nentries=0 text=
##########################
following the configuration for back-ldap:
database ldap
suffix "o=bazbaz"
uri ldap://10.2.163.13:389
rootdn "cn=PEX,o=bazbaz"
rootpw secret
idle-timeout 301
rebind-as-user yes
single-conn yes
chase-referrals no
acl-bind bindmethod=simple
binddn="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz"
credentials=supersecret
13 years, 3 months
Re: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s
by Kurt＠OpenLDAP.org
On Jun 2, 2010, at 11:11 AM, Michael Str=F6der wrote:
> Kurt(a)OpenLDAP.org wrote:
>> However, one issue I have with this code is that highly dependent =3D
>> behaviors which, aside from not be standardized, aren't even =
specified =3D
>> in RFCs. For instance, there is no RFC describing dnsHostName or =3D
>> ldapServiceName or any specification detailing how GSS-SPNEGO is to =
be =3D
>> used in LDAP. Without a formal specification (e.g., RFC), I oppose =3D=
>> release of this code. That is, it should stay HEAD only until such =
time =3D
>> that a formal specification (e.g., RFC) is available.
>=20
> Kurt, I somewhat can understand your concerns.
> But as a general answer to your comment above: There is already a lot =
of code
> in OpenLDAP for which no RFC or at least an I-D was specified but =
which serves
> a certain use-case. Strictly (following your statement above) speaking =
one
> would have to hunk out all the stuff only specified in I-Ds.
An I-D would be a start. I would think there's a number of interesting =
security considerations that would bubble up if someone would ever have =
taken the time to submit a specification regarding use of SPNEGO in SASL =
and in application protocols such as LDAP to an open standards =
organization such as the IETF.
> So I don't see
> the strong need to be overly strict here.
It's long been a stated goal of the project to promote interoperability =
through open standards. This work seems more to come from a community =
whose stated goal is to behave like one particular vendor. I'm not a =
fan of chasing any particular vendor.
> Quality of certain code is another story. But I cannot comment on =
this.
How can one independently verify the code acts as intended without a =
specification of the intended behavior? (Saying it should act like =
some particular commercial product, is not a specification.)
-- Kurt
>=20
> Ciao, Michael.
13 years, 3 months
Re: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s
by michael＠stroeder.com
Kurt(a)OpenLDAP.org wrote:
> However, one issue I have with this code is that highly dependent =
> behaviors which, aside from not be standardized, aren't even specified =
> in RFCs. For instance, there is no RFC describing dnsHostName or =
> ldapServiceName or any specification detailing how GSS-SPNEGO is to be =
> used in LDAP. Without a formal specification (e.g., RFC), I oppose =
> release of this code. That is, it should stay HEAD only until such time =
> that a formal specification (e.g., RFC) is available.
Kurt, I somewhat can understand your concerns.
But as a general answer to your comment above: There is already a lot of code
in OpenLDAP for which no RFC or at least an I-D was specified but which serves
a certain use-case. Strictly (following your statement above) speaking one
would have to hunk out all the stuff only specified in I-Ds. So I don't see
the strong need to be overly strict here.
Quality of certain code is another story. But I cannot comment on this.
Ciao, Michael.
13 years, 3 months
