Bug 1367689

Could you tell us from which version to which version you upgraded?

What is the current version of 389-ds-base?
$ rpm -q 389-ds-base

And you figured out the cause of the problem.  

Did you have a chance to export the DB contents by db2ldif?
If you modify your problematic ACI with the one containing the normalized dn, and import it back to the server, does your server start?

Please note that if your server is replicated, you may need to export with '-r'.  Otherwise, you may need to run consumer initialization.

Thanks.

Hi Noriko,

--> Could you tell us from which version to which version you upgraded?
--> What is the current version of 389-ds-base?
The issue occurs, while upgrade from the 389-ds-base 1.2.0 to 1.2.9.9 I know its quite an old version. But it can occur even in 389-ds-base 1.2.11.29. I didn't checked in the latest version, as we not integrated it in our environment.
You basically need not to upgrade version x->y, it can happen simply by simply adding the that ACI. All DN are normalized during server start, but ACIs are left out.

--> And you figured out the cause of the problem.
Yes, That ACI ONLY is the problem.
--> Did you have a chance to export the DB contents by db2ldif?
--> If you modify your problematic ACI with the one containing the normalized dn, and import it back to the server, does your server start?
I never faced any issue with the server start. The server start, even if their is an error while parsing that ACI. While debugging, I have identified, slapi_sdn_issuffix() compares the normalised DN is suffix of non-normalised DN.

Let me know, in case you need any other information.

Thanks & Regards,
Hemant Yadav

Yes, if I remove the problematic ACI with the one containing the normalised DN, the error is not logged. If I manually ESC-HEX-HEX the ACI target (see below), then the ACI parse error doesn't occur. Note that server always start, irrespective of error.

aci: (targetattr = "*")(target = "ldap:///cn="o\3Dboj.or.jp",cn=mapping tree,cn=config")(  version 3.0;  acl "replication management";  allow (all) userdn ="ldap:///uid=all";)

Originally, below is passed to function slapi_dn_issuffix(), which is comparing normalised suffix with non-normalised target.
avaValue->bv_val= 	cn=o=boj.or.jp,cn=mapping tree,cn=config
dn= 			cn=o\3dboj.or.jp,cn=mapping tree,cn=config
Obviously both are different, if string comparison is made. :)

I have changed the code to below in aclparse.c file.
-> Initialising the DN in Slapi_DN targdn by ref from bv_val.
-> Normalising through slapi_sdn_get_ndn(), which will internally normalise the ndn by using the dn.
-> But unfortunately slapi_sdn_init_dn_byref() is not setting anything using the passed reference.

if (aci_item->target) {
	if (aci_item->aci_type & ACI_TARGET_DN) {
		char           *avaType;
		struct berval   *avaValue;
		const char      *dn;
		Slapi_Filter            *f;
		Slapi_DN *targdn;
		const char      *norm_targ_dn;
		
		// Set the location
		dn = slapi_sdn_get_ndn ( aci_item->aci_sdn );
		
		// Set the target DN, with normalised value, as ACI are being ignored for normalisation
		f = aci_item->target;
		slapi_filter_get_ava ( f, &avaType, &avaValue );
		slapi_sdn_init_dn_byref(&targdn, avaValue->bv_val);
		norm_targ_dn = slapi_sdn_get_ndn(targdn);
		
	slapi_log_error( SLAPI_LOG_FATAL, plugin_name,"hemant3 avaValue->bv_val= %s \n, dn= %s \n",avaValue->bv_val,dn);
	slapi_log_error( SLAPI_LOG_FATAL, plugin_name,"hemant3 targdn->dn=%s \n,targdn->ndn=%s \n",targdn->dn,targdn->ndn);
	slapi_log_error( SLAPI_LOG_FATAL, plugin_name,"hemant3 norm_targ_dn = %s \n,dn= %s \n",norm_targ_dn,dn);
	
		if (!slapi_dn_issuffix( norm_targ_dn, dn))
			return ACL_INVALID_TARGET;
	}
}

Here is the values that came out:
avaValue->bv_val= 	cn=o=boj.or.jp,cn=mapping tree,cn=config
dn= 			cn=o\3dboj.or.jp,cn=mapping tree,cn=config
targdn->dn=		(null)
targdn->ndn=		(null)
norm_targ_dn = 		(null)

Cheers,
Hemant

Could you try escaping the double quotes in the double quotes?
Before:
aci: (targetattr = "*")(target = "ldap:///cn="o=boa.or.ap",cn=mapping tree,cn= config")(  version 3.0;  acl "replication management";  allow (all) userdn =" ldap:///uid=all";)

After:
aci: (targetattr = "*")(target = "ldap:///cn=\"o=boa.or.ap\",cn=mapping tree,cn= config")(  version 3.0;  acl "replication management";  allow (all) userdn =" ldap:///uid=all";)

Hi Noriko,

I have tried as you said, but slapd start still throwing the parsing error:
[24/Aug/2016:18:59:43 +051800] -Directory server starting up
[24/Aug/2016:18:59:44 +051800] NSACLPlugin - ACL PARSE ERR(rv=-8): (targetattr = "*
[24/Aug/2016:18:59:44 +051800] NSACLPlugin - Error: This  ((targetattr = "*")(target = "ldap:///cn=\"o=boa.or.ap\",cn=mapping tree,cn=config"
)(  version 3.0;  acl "replication management";  allow (all) userdn ="ldap:///uid=all";)) ACL will not be considered for evaluation because o
f syntax errors.
[24/Aug/2016:18:59:44 +051800] - slapd started.  Listening on All Interfaces port 389 for LDAP requests

Thanks,
Hemant

Hello Hemant,

I'm afraid that the 389-ds-base version you mentioned is quite old, too.
  389-ds-base-1.2.11.29 -- Date: Fri Apr 4 10:58:53 2014 -0700

On RHEL-6.x, we are supporting 389-ds-base-1.2.11.15-##.el6*.
The latest available one for CentOS 6 is 389-ds-base-1.2.11.15-74, which was built on the 3rd of March, 2016.  Please see this cite, for instance.
http://mirror.centos.org/centos/6/os/x86_64/Packages/

Could you please try the latest build?

Thanks.

Hello Hemant,

Can we have any update regarding this bug?

If none, may we close this bug?

Thanks.

Hi Noriko, Right now we dont have the latest version of ds-base integrated in our environment. We are planning to integrate it in June 2017. I think you can close this, I will re-open this, if the issue still persist in latest version of ds-base.

(In reply to Hemant Yadav from comment #10)
> Hi Noriko, Right now we dont have the latest version of ds-base integrated
> in our environment. We are planning to integrate it in June 2017. I think
> you can close this, I will re-open this, if the issue still persist in
> latest version of ds-base.

Thank you for your update, Hemant.

Yes, if you run into this problem, please feel free to reopen it.

Closing this bug for now.