Bug 555577

This and the other two issues you raised are about the fact that 389 does not support strict DN syntax with LDAPv3 escapes instead of double quotes.  We don't fully support RFC4514.  This is related to the other issue you brought up:
https://www.redhat.com/archives/fedora-directory-users/2009-December/msg00185.html

For the next major release, we need to clean up these and related issues.

*** Bug 560747 has been marked as a duplicate of this bug. ***

(In reply to comment #3)
> *** Bug 560747 has been marked as a duplicate of this bug. ***    

Please note that this bug is now quite serous...  Backend add/modify/modrdn/delete functions are checking slapi_dn_syntax_check before the operation.
ldap_result_code = slapi_dn_syntax_check(pb, dn, 1);

Because of the failure, registering the server to the config directory does not work...  I.e., setup-ds-admin.pl fails, as well.

Should we comment out these calls until we solve this problem?
$ egrep slapi_dn_syntax_check */*.c
back-ldbm/ldbm_add.c:			ldap_result_code = slapi_dn_syntax_check(pb, dn, 1);
back-ldbm/ldbm_delete.c:	ldap_result_code = slapi_dn_syntax_check(pb, addr->dn, 1);
back-ldbm/ldbm_modify.c:	ldap_result_code = slapi_dn_syntax_check(pb, addr->dn, 1);
back-ldbm/ldbm_modrdn.c:            ldap_result_code = slapi_dn_syntax_check(pb, new_addr.dn, 1);
back-ldbm/ldbm_modrdn.c:            ldap_result_code = slapi_dn_syntax_check(pb, old_addr->dn, 1);

The same syntax validation problem applies also to replication agreement description entries in cn=config. Strangely enough, it does not mention entrydn, only nsds5replicaChangesSentSinceStartup, nsds5replicaLastInitStart and nsds5replicaLastInitEnd:

[01/Feb/2010:21:07:35 +0100] syntax-plugin - Syntax validate task starting (base: "cn=config", filter: "(objectclass=*)") ...
[01/Feb/2010:21:07:35 +0100] syntax-plugin - Entry "cn=Replication from ldap-adm.polytechnique.fr to ldap-ens.polytechnique.fr,cn=replica,cn="dc=id,dc=polytechnique,dc=edu",cn=mapping tree,cn=config" violates syntax.
nsds5replicaChangesSentSinceStartup: value #0 invalid per syntax
nsds5replicaLastInitStart: value #0 invalid per syntax
nsds5replicaLastInitEnd: value #0 invalid per syntax
[01/Feb/2010:21:07:35 +0100] syntax-plugin - Entry "cn=Replication from ldap-adm.polytechnique.fr to ldap-lab.polytechnique.fr,cn=replica,cn="dc=id,dc=polytechnique,dc=edu",cn=mapping tree,cn=config" violates syntax.
nsds5replicaChangesSentSinceStartup: value #0 invalid per syntax
nsds5replicaLastInitStart: value #0 invalid per syntax
nsds5replicaLastInitEnd: value #0 invalid per syntax
[01/Feb/2010:21:07:35 +0100] syntax-plugin - Syntax validate task complete.  Found 2 invalid entries.

An important note: the syntax validation errors reported above (cn=config & o=NetscapeRoot)are all generated with

nsslapd-dn-validate-strict: off

The syntax problems with nsds5replicaChangesSentSinceStartup and nsds5replicaLastInitStart and nsds5replicaLastInitEnd are unrelated to the other DN syntax problems with the embedded quotes.

> Please note that this bug is now quite serous...  Backend
> add/modify/modrdn/delete functions are checking slapi_dn_syntax_check before
> the operation.
> ldap_result_code = slapi_dn_syntax_check(pb, dn, 1);
> 
> Because of the failure, registering the server to the config directory does not
> work...  I.e., setup-ds-admin.pl fails, as well.
> 
> Should we comment out these calls until we solve this problem?

Can we change these to only use strict DN syntax checking if nsslapd-dn-validate-strict is on?

> $ egrep slapi_dn_syntax_check */*.c
> back-ldbm/ldbm_add.c:   ldap_result_code = slapi_dn_syntax_check(pb, dn, 1);
> back-ldbm/ldbm_delete.c: ldap_result_code = slapi_dn_syntax_check(pb, addr->dn,
> 1);
> back-ldbm/ldbm_modify.c: ldap_result_code = slapi_dn_syntax_check(pb, addr->dn,
> 1);
> back-ldbm/ldbm_modrdn.c:            ldap_result_code =
> slapi_dn_syntax_check(pb, new_addr.dn, 1);
> back-ldbm/ldbm_modrdn.c:            ldap_result_code =
> slapi_dn_syntax_check(pb, old_addr->dn, 1);

(In reply to comment #7)
> Can we change these to only use strict DN syntax checking if
> nsslapd-dn-validate-strict is on?

A good idea!  I'm testing the code now...
> 
> > $ egrep slapi_dn_syntax_check */*.c
> > back-ldbm/ldbm_add.c:   ldap_result_code = slapi_dn_syntax_check(pb, dn, 1);
> > back-ldbm/ldbm_delete.c: ldap_result_code = slapi_dn_syntax_check(pb, addr->dn,
> > 1);
> > back-ldbm/ldbm_modify.c: ldap_result_code = slapi_dn_syntax_check(pb, addr->dn,
> > 1);
> > back-ldbm/ldbm_modrdn.c:            ldap_result_code =
> > slapi_dn_syntax_check(pb, new_addr.dn, 1);
> > back-ldbm/ldbm_modrdn.c:            ldap_result_code =
> > slapi_dn_syntax_check(pb, old_addr->dn, 1);

Created attachment 388144 [details]
git patch file

[See comment 7 of the bug]
DistinguishName validation slapi_dn_syntax_check should be
called only when nsslapd-dn-validate-strict is on.

(In reply to comment #9)
> Created an attachment (id=388144) [details]
> git patch file
> 
> [See comment 7 of the bug]
> DistinguishName validation slapi_dn_syntax_check should be
> called only when nsslapd-dn-validate-strict is on.    

Reviewed by Rich (Thank you!!!)

Pushed to master.

$ git merge work
Updating 1378b05..c9c424c
Fast forward
 ldap/servers/slapd/back-ldbm/ldbm_add.c    |   13 ++++++++-----
 ldap/servers/slapd/back-ldbm/ldbm_delete.c |   13 ++++++++-----
 ldap/servers/slapd/back-ldbm/ldbm_modify.c |   13 ++++++++-----
 ldap/servers/slapd/back-ldbm/ldbm_modrdn.c |   26 ++++++++++++++++----------
 4 files changed, 40 insertions(+), 25 deletions(-)
$ git push
Counting objects: 19, done.
Delta compression using 4 threads.
Compressing objects: 100% (10/10), done.
Writing objects: 100% (10/10), 1.29 KiB, done.
Total 10 (delta 8), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
   1378b05..c9c424c  master -> master

I've just talked to Nathan.  He explained to me that "strict" is for the strength of the DN validation.  It should be confusing to use the configuration parameter for turning on/off the validation itself.  I'm reverting the change I made.  Instead, I'm going to fix the Administration server's template files to escape '"'...

(In reply to comment #10)
> (In reply to comment #9)
> > Created an attachment (id=388144) [details] [details]
> > git patch file
> > 
> > [See comment 7 of the bug]
> > DistinguishName validation slapi_dn_syntax_check should be
> > called only when nsslapd-dn-validate-strict is on.    
> 
> Reviewed by Rich (Thank you!!!)
> 
> Pushed to master.
> 
> $ git merge work
> Updating 1378b05..c9c424c
> Fast forward
>  ldap/servers/slapd/back-ldbm/ldbm_add.c    |   13 ++++++++-----
>  ldap/servers/slapd/back-ldbm/ldbm_delete.c |   13 ++++++++-----
>  ldap/servers/slapd/back-ldbm/ldbm_modify.c |   13 ++++++++-----
>  ldap/servers/slapd/back-ldbm/ldbm_modrdn.c |   26 ++++++++++++++++----------
>  4 files changed, 40 insertions(+), 25 deletions(-)
> $ git push
> Counting objects: 19, done.
> Delta compression using 4 threads.
> Compressing objects: 100% (10/10), done.
> Writing objects: 100% (10/10), 1.29 KiB, done.
> Total 10 (delta 8), reused 0 (delta 0)
> To ssh://git.fedorahosted.org/git/389/ds.git
>    1378b05..c9c424c  master -> master

Re-examing the problem on the latest 389-ds-base:
# rpm -q 389-ds-base
389-ds-base-1.2.8-0.8.rc2.fc14.i386

The server has 3 entries under cn=mapping tree:
$ ldapsearch ... -D 'cn=directory manager' -w <pw> -b "cn=mapping tree,cn=config" "(objectclass=*)" dn
dn: cn=mapping tree,cn=config
dn: cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
dn: cn=o\3Dnetscaperoot,cn=mapping tree,cn=config
dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config

nsslapd-dn-validate-strict is off:
# grep validate /etc/dirsrv/slapd-ID/dse.ldif
nsslapd-dn-validate-strict: off

Run syntax-validate.pl task:
# syntax-validate.pl -v -D 'cn=directory manager' -w <pw> -b "o=netscaperoot"

[error log]
[..] syntax-plugin - Syntax validate task starting (base: "o=netscaperoot", filter: "(objectclass=*)") ...
[..] syntax-plugin - Syntax validate task complete.  Found 0 invalid entries.

These steps can be used to verify the bug.

Yes, i confirm that there is no problem in o=netscaperoot.


However, i still have the syntax validation problem in cn=config for replication agreements (have not tested with 1.2.8rcx but i think it has not changed):

nsds5replicaChangesSentSinceStartup: value #0 invalid per syntax
nsds5replicaLastInitStart: value #0 invalid per syntax
nsds5replicaLastInitEnd: value #0 invalid per syntax

I think it's not the dn parsing problem, it is the schema definitions of syntaxes for these attributes and the values that do not correspond to the syntax :

(has integer syntax)nsds5replicaChangesSentSinceStartup: 1:11157/0 3:176/0
(has generalized time syntax)nsds5replicaLastInitStart: 0
(has generalized time syntax)nsds5replicaLastInitEnd: 0


attributeTypes: ( 2.16.840.1.113730.3.1.687 NAME 'nsds5replicaChangesSentSinceStartup' DESC 'Netscape defined attribute type' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE NO-USER-MODIFICATION X-ORIGIN 'Netscape Directory Server' )

attributeTypes: ( 2.16.840.1.113730.3.1.807 NAME 'nsds5replicaLastInitStart' DESC 'Netscape defined attribute type' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER-MODIFICATION X-ORIGIN 'Netscape Directory Server' )

attributeTypes: ( 2.16.840.1.113730.3.1.808 NAME 'nsds5replicaLastInitEnd' DESC 'Netscape defined attribute type' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER-MODIFICATION X-ORIGIN 'Netscape Directory Server' )


Maybe a separate bugzilla entry should be opened to take care of this bug...

Thanks for the clarification, Andrey!

I've opened a new bug for the replication agreement:
Bug 692211 - Replication agreements contain attributes which have invalid syntax

[root@rhel61 ~]# rpm -q 389-ds-base
389-ds-base-1.2.8.2-1.el6_1.7.x86_64


followed comment#12
=======================
[root@rhel61 ~]# ldapsearch -x -h localhost -p 389 -D "cn=Directory Manager" -w Secret123 -b "cn=mapping tree,cn=config" "(objectclass=*)" dn

# mapping tree, config
dn: cn=mapping tree,cn=config
# dc\3Dpnq\2Cdc\3Dredhat\2Cdc\3Dcom, mapping tree, config
dn: cn=dc\3Dpnq\2Cdc\3Dredhat\2Cdc\3Dcom,cn=mapping tree,cn=config
# o\3Dnetscaperoot, mapping tree, config
dn: cn=o\3Dnetscaperoot,cn=mapping tree,cn=config


[root@rhel61 ~]# grep validate /etc/dirsrv/slapd-rhel61/dse.ldif
nsslapd-dn-validate-strict: off
nsslapd-pluginInitfunc: syntax_validate_task_init
dn: cn=syntax validate,cn=tasks,cn=config
cn: syntax validate

[root@rhel61 ~]# /usr/lib64/dirsrv/slapd-rhel61/syntax-validate.pl -v -D "cn=Directory Manager" -w Secret123 -b "o=NetscapeRoot"
ldap_initialize( ldap://rhel61.pnq.redhat.com:389 )
add objectclass:
	top
	extensibleObject
add cn:
	syntax_validate_2011_8_1_17_22_29
add basedn:
	o=NetscapeRoot
adding new entry "cn=syntax_validate_2011_8_1_17_22_29, cn=syntax validate, cn=tasks, cn=config"
modify complete

error logs
-----------
[01/Aug/2011:17:22:29 +051800] syntax-plugin - Syntax validate task starting (base: "o=NetscapeRoot", filter: "(objectclass=*)") ...
[01/Aug/2011:17:22:29 +051800] syntax-plugin - Syntax validate task complete.  Found 0 invalid entries.


Hence VERIFIED.