Issue 8404 - Fix for an assertion failure when olcDbRewrite is modified on a meta or asyncmeta database
Summary: Fix for an assertion failure when olcDbRewrite is modified on a meta or async...
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: 2.5.4
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
: 8239 8482 (view as issue list)
Depends on:
Blocks:
 
Reported: 2016-04-14 13:28 UTC by Nadezhda Ivanova
Modified: 2021-02-22 18:16 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Nadezhda Ivanova 2016-04-14 13:28:18 UTC
Full_Name: Nadezhda Ivanova
Version: 2.5
OS: Ubuntu 14.04
URL: ftp://ftp.openldap.org/incoming/nadezhda-ivanova-160414.patch
Submission from: (NULL) (78.83.54.234)


The problem was reproduced when attempting to modify the dynamic configuration
of meta and asyncmeta rewrite engine. On a meta database that has rewrite
enabled and some rewrite rules configured, execute ldapmodify with the following
LDIF:
dn: olcMetaSub={0}uri,olcDatabase={1}meta,cn=config
replace: olcDbRewrite
olcDbRewrite: rewriteEngine "off"

Comment 1 Howard Chu 2016-04-28 16:25:46 UTC
nivanova@symas.com wrote:
> Full_Name: Nadezhda Ivanova
> Version: 2.5
> OS: Ubuntu 14.04
> URL: ftp://ftp.openldap.org/incoming/nadezhda-ivanova-160414.patch
> Submission from: (NULL) (78.83.54.234)
>
>
> The problem was reproduced when attempting to modify the dynamic configuration
> of meta and asyncmeta rewrite engine. On a meta database that has rewrite
> enabled and some rewrite rules configured, execute ldapmodify with the following
> LDIF:
> dn: olcMetaSub={0}uri,olcDatabase={1}meta,cn=config
> replace: olcDbRewrite
> olcDbRewrite: rewriteEngine "off"

Hm, multiple problems with this patch:

> diff --git a/servers/slapd/back-asyncmeta/config.c b/servers/slapd/back-asyncmeta/config.c
> index 1801a55..a4fbb91 100644
> --- a/servers/slapd/back-asyncmeta/config.c
> +++ b/servers/slapd/back-asyncmeta/config.c
> @@ -1797,14 +1797,66 @@ asyncmeta_back_cf_gen( ConfigArgs *c )
>
>  		case LDAP_BACK_CFG_SUFFIXM:	/* unused */
>  		case LDAP_BACK_CFG_REWRITE:
> -			if ( mt->mt_rwmap.rwm_bva_rewrite ) {
> -				ber_bvarray_free( mt->mt_rwmap.rwm_bva_rewrite );
> -				mt->mt_rwmap.rwm_bva_rewrite = NULL;
> -			}
> -			if ( mt->mt_rwmap.rwm_rw )
> +		{
> +			char			*argv0;
> +			if ( c->valx >= 0 ) {
> +				int i;
> +				
> +				for ( i = 0; !BER_BVISNULL( &mt->mt_rwmap.rwm_bva_rewrite[ i ] ); i++ )

Need a semicolon for the empty for-loop. Or, if it's intended that the 
following if-block is part of the loop, it needs to be properly enclosed in 
braces and indented.

> +				
> +				if ( c->valx >= i ) {
> +					rc = 1;
> +					break;
> +				}

> +				ber_memfree( mt->mt_rwmap.rwm_bva_rewrite[ c->valx ].bv_val );
> +				for ( i = c->valx; !BER_BVISNULL( &mt->mt_rwmap.rwm_bva_rewrite[ i + 1 ] ); i++ )
> +				{
> +					mt->mt_rwmap.rwm_bva_rewrite[ i ] = mt->mt_rwmap.rwm_bva_rewrite[ i + 1 ];
> +				}

> +				BER_BVZERO( &mt->mt_rwmap.rwm_bva_rewrite[ i ] );
> +
>  				rewrite_info_delete( &mt->mt_rwmap.rwm_rw );
> -			break;
> +				assert( mt->mt_rwmap.rwm_rw == NULL );
> +
> +				rc = asyncmeta_rwi_init( &mt->mt_rwmap.rwm_rw );
> +
> +				for ( i = 0; !BER_BVISNULL( &mt->mt_rwmap.rwm_bva_rewrite[ i ] ); i++ )
> +				{
> +					ConfigArgs ca = { 0 };
> +
> +					ca.line = mt->mt_rwmap.rwm_bva_rewrite[ i ].bv_val;
> +					ca.argc = 0;

Unnecessary initialization, you already set all of ca = {0}.

> +					init_config_argv( &ca );
> +					config_parse_ldif( &ca );
> +
> +					argv0 = ca.argv[ 0 ];

What is argv0 being saved for?

> +					if ( !strcasecmp( ca.argv[0], "suffixmassage" )) {
> +						rc = asyncmeta_suffixm_config( &ca, ca.argc, ca.argv, mt );
> +					} else {
> +						rc = rewrite_parse( mt->mt_rwmap.rwm_rw,
> +								    c->fname, c->lineno, ca.argc, ca.argv );
> +					}
> +				
> +					ca.argv[ 0 ] = argv0;

Why is argv0 being restored? All you're doing after this is freeing ca.argv 
anyway.
> +
> +					ch_free( ca.tline );
> +					ch_free( ca.argv );
>
> +					assert( rc == 0 );
> +				}
> +
> +			} else if ( mt->mt_rwmap.rwm_rw != NULL ) {
> +				if ( mt->mt_rwmap.rwm_bva_rewrite ) {
> +					ber_bvarray_free( mt->mt_rwmap.rwm_bva_rewrite );
> +					mt->mt_rwmap.rwm_bva_rewrite = NULL;
> +				}
> +				if ( mt->mt_rwmap.rwm_rw )
> +					rewrite_info_delete( &mt->mt_rwmap.rwm_rw );
> +				
> +				asyncmeta_rwi_init( &mt->mt_rwmap.rwm_rw );
> +			}		
> +		}
> +			break;
>  		case LDAP_BACK_CFG_MAP:
>  			if ( mt->mt_rwmap.rwm_bva_map ) {
>  				ber_bvarray_free( mt->mt_rwmap.rwm_bva_map );


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

Comment 2 Nadezhda Ivanova 2017-09-12 14:25:18 UTC
A new patch for this issue is uploaded at ftp://ftp.openldap.org/incoming/nadezhda-ivanova-170912.patch

Since asyncmeta no longer uses the rewrite engine, that part of the fix has become irrelevant and is therefore not included.

----- Original Message -----
From: openldap-its@OpenLDAP.org
To: nivanova@symas.com
Sent: Thursday, April 14, 2016 4:28:20 PM
Subject: Re: (ITS#8404) Fix for an assertion failure when olcDbRewrite is modified on a meta or asyncmeta database

*** THIS IS AN AUTOMATICALLY GENERATED REPLY ***

Thanks for your report to the OpenLDAP Issue Tracking System.  Your
report has been assigned the tracking number ITS#8404.

One of our support engineers will look at your report in due course.
Note that this may take some time because our support engineers
are volunteers.  They only work on OpenLDAP when they have spare
time.

If you need to provide additional information in regards to your
issue report, you may do so by replying to this message.  Note that
any mail sent to openldap-its@openldap.org with (ITS#8404)
in the subject will automatically be attached to the issue report.

	mailto:openldap-its@openldap.org?subject=(ITS#8404)

You may follow the progress of this report by loading the following
URL in a web browser:
    http://www.OpenLDAP.org/its/index.cgi?findid=8404

Please remember to retain your issue tracking number (ITS#8404)
on any further messages you send to us regarding this report.  If
you don't then you'll just waste our time and yours because we
won't be able to properly track the report.

Please note that the Issue Tracking System is not intended to
be used to seek help in the proper use of OpenLDAP Software.
Such requests will be closed.

OpenLDAP Software is user supported.
	http://www.OpenLDAP.org/support/

--------------
Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.

Comment 3 Quanah Gibson-Mount 2017-09-12 16:14:48 UTC
changed notes
Comment 4 Nadezhda Ivanova 2017-09-12 16:22:23 UTC
IPR for this ITS:

The attached files are derived from OpenLDAP Software. All of the modifications
to OpenLDAP Software represented in the following patch were developed by Symas
Corporation. Symas Corporation has not assigned rights and/or interest in this
work to any party. I, Nadezhda Ivanova, am authorized by Symas Corporation, my
employer, to release this work under the following terms.

The attached modifications to OpenLDAP Software are subject to the following
notice:

Copyright 2017 Symas Corporation
Redistribution and use in source and binary forms, with or without modification,
are permitted only as authorized by the OpenLDAP Public License.

Comment 5 Quanah Gibson-Mount 2017-09-12 17:03:15 UTC
changed notes
Comment 6 Quanah Gibson-Mount 2017-10-06 17:55:37 UTC
changed notes
changed state Open to Test
moved from Incoming to Software Bugs
Comment 7 Quanah Gibson-Mount 2017-10-11 19:40:13 UTC
changed notes
changed state Test to Release
Comment 8 OpenLDAP project 2018-03-22 19:25:06 UTC
fixed in master
fixed in RE24 (2.4.46)
Comment 9 Quanah Gibson-Mount 2018-03-22 19:25:06 UTC
changed notes
changed state Release to Closed
Comment 10 Howard Chu 2021-02-03 16:53:51 UTC
*** Issue 8239 has been marked as a duplicate of this issue. ***
Comment 11 Quanah Gibson-Mount 2021-02-22 18:16:30 UTC
*** Issue 8482 has been marked as a duplicate of this issue. ***