Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1367689 - NSACLPlugin - ACL PARSE ERR as the directory server starts.
Summary: NSACLPlugin - ACL PARSE ERR as the directory server starts.
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.0
Hardware: ia64
OS: All
unspecified
high
Target Milestone: pre-dev-freeze
: 7.4
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-17 08:56 UTC by Hemant Yadav
Modified: 2016-11-10 01:40 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-10 01:40:31 UTC


Attachments (Terms of Use)

Description Hemant Yadav 2016-08-17 08:56:26 UTC
Hi, 
Recently I have identified an issue with the 389 Directory Server's ACL plugin. The issue is related to the upgrade of the old DN format to new DN format. I have already read the below documentation.
http://directory.fedoraproject.org/docs/389ds/howto/howto-upgrade-to-new-dn-format.html

Does the ACI attribute also get normalised ?

Description of problem:
Every time I start the directory server instance, I get the below error in "/var/opt/dirsrv/slapd-instance/log/errors"
[17/Aug/2016:17:38:46 +051800] NSACLPlugin - ACL PARSE ERR(rv=-8): (targetattr = "*
[17/Aug/2016:17:38:46 +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 ofsyntax errors.
[17/Aug/2016:17:38:46 +051800] - slapd started.  Listening on All Interfaces port 389 for LDAP requests

The reason for this error is the below ACI added:
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";)

The ACI is not normalised. In code "slapi_sdn_issuffix" compares the normalised suffix with non-normalised suffix and found no match leading to this error.
File: \ldap\servers\plugins\acl\aclparse.c

I have provided suffix DN as "o=boa.or.ap". So I have below entries in the dse.ldif file.
dn: cn="o=boa.or.ap",cn=mapping tree,cn=config
objectclass: top
objectclass: extensibleObject
objectclass: nsMappingTree
cn: "o=boa.or.ap"
cn: o=boa.or.ap
nsslapd-state: backend
nsslapd-backend: userRoot
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 we start the directory server, the dse.ldif file entry looks like below, means normalisation has happened for DN and it is properly ESC HEX HEX.
dn: cn=o\3Dboa.or.ap,cn=mapping tree,cn=config
objectClass: top
objectClass: extensibleObject
objectClass: nsMappingTree
cn: "o=boa.or.ap"
cn: o=boa.or.ap
nsslapd-state: backend
nsslapd-backend: userRoot
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";)

But the ACI attribute is not upgraded to new format. My question is, are ACI attributes not a part of normalisation activity and only DNs are normalised to new format ? If yes then we should log the WARNING and not the ERROR in this scenario. Else we should also normalise ACI attributes during the server start and it should be properly stored with escape sequence in dse.ldif file.

Version-Release number of selected component (if applicable):
The issue occurs, while upgrade from the 389 directory server 1.2.0 to 1.2.9.9, however I didn't see any changes in this regard even in the latest version also.

How reproducible:
Every time the directory server instance starts, the error is logged for all  entry that particular ACI attribute.

Steps to Reproduce:
Fastest way to reproduce is:
-> Install Directory Server and Configure it with suffix DN o=boa.or.ap
-> Stop the DS instance.
-> Add the below ACI in the dse.ldif file
For dn: cn="o=boa.or.ap",cn=mapping tree,cn=config add below ACI
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";)
-> Start the Directory server instance. See the error log.

Actual results:
[17/Aug/2016:17:38:46 +051800] NSACLPlugin - ACL PARSE ERR(rv=-8): (targetattr = "*

Expected results:
Either the ERROR should be converted to Warning or ACI also should also be normalised.

Additional info:

Cheers,
Hemant Yadav

Comment 1 Noriko Hosoi 2016-08-17 16:55:42 UTC
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.

Comment 3 Hemant Yadav 2016-08-18 05:08:48 UTC
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

Comment 4 Hemant Yadav 2016-08-18 05:23:45 UTC
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";)

Comment 5 Hemant Yadav 2016-08-18 11:41:12 UTC
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

Comment 6 Noriko Hosoi 2016-08-19 16:55:06 UTC
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";)

Comment 7 Hemant Yadav 2016-08-24 08:00:04 UTC
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

Comment 8 Noriko Hosoi 2016-08-24 16:06:44 UTC
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.

Comment 9 Noriko Hosoi 2016-11-04 18:02:34 UTC
Hello Hemant,

Can we have any update regarding this bug?

If none, may we close this bug?

Thanks.

Comment 10 Hemant Yadav 2016-11-07 06:13:05 UTC
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.

Comment 11 Noriko Hosoi 2016-11-10 01:40:31 UTC
(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.


Note You need to log in before you can comment on or make changes to this bug.