Bug 555577 - Syntax validation fails for "ou=NetscapeRoot" tree
Summary: Syntax validation fails for "ou=NetscapeRoot" tree
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Schema
Version: 1.2.1
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Viktor Ashirov
URL:
Whiteboard:
: 560747 (view as bug list)
Depends On:
Blocks: 639035 389_1.2.8
TreeView+ depends on / blocked
 
Reported: 2010-01-14 20:12 UTC by Andrey Ivanov
Modified: 2015-12-07 17:15 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-07 17:15:03 UTC


Attachments (Terms of Use)
git patch file (5.81 KB, patch)
2010-02-01 21:26 UTC, Noriko Hosoi
nhosoi: review?
rmeggins: review+
Details | Diff

Description Andrey Ivanov 2010-01-14 20:12:32 UTC
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729)

Syntax validation task generates validation errors on 3 entries in "ou=NetscapeRoot" tree after a default installation.

Reproducible: Always

Steps to Reproduce:
1. Install 389 1.2.5, setup-ds-admin.pl
2. Run the synytax validation task :
/usr/lib64/dirsrv/slapd-ldap-model/syntax-validate.pl -v -D
"cn=Directory Manager" -w '<password>' -b "o=NetscapeRoot"
3. Check the error log
Actual Results:  
[25/Dec/2009:20:07:23 +0100] syntax-plugin - Syntax validate task
starting (base: "o=NetscapeRoot", filter: "(objectclass=*)") ...
[25/Dec/2009:20:07:23 +0100] syntax-plugin - Entry "ou="uid=admin,
ou=Administrators, ou=TopologyManagement,
o=NetscapeRoot",ou=UserPreferences, ou=polytechnique.fr,
o=NetscapeRoot" violates syntax.
entrydn: value #0 invalid per syntax
[25/Dec/2009:20:07:23 +0100] syntax-plugin - Entry
"ou="cn=slapd-ldap-model, cn=389 Directory Server, cn=Server Group,
cn=ldap-model.polytechnique.fr, ou=polytechnique.fr,
o=NetscapeRoot",ou=UserPreferences, ou=polytechnique.fr,
o=NetscapeRoot" violates syntax.
entrydn: value #0 invalid per syntax
[25/Dec/2009:20:07:23 +0100] syntax-plugin - Entry
"ou="cn=admin-serv-ldap-model, cn=389 Administration Server, cn=Server
Group, cn=ldap-model.polytechnique.fr, ou=polytechnique.fr,
o=NetscapeRoot",ou=UserPreferences, ou=polytechnique.fr,
o=NetscapeRoot" violates syntax.
entrydn: value #0 invalid per syntax
[25/Dec/2009:20:07:23 +0100] syntax-plugin - Syntax validate task
complete.  Found 3 invalid entries.

Expected Results:  
The syntax validation should return no errors.

There is something in the entrydn syntax the validation mechanism does not like - either spaces in the quoted parts of the DNs or the double quotes in the DN...

Comment 1 Rich Megginson 2010-01-14 20:26:54 UTC
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.

Comment 3 Noriko Hosoi 2010-02-01 19:56:20 UTC
*** Bug 560747 has been marked as a duplicate of this bug. ***

Comment 4 Noriko Hosoi 2010-02-01 20:03:39 UTC
(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);

Comment 5 Andrey Ivanov 2010-02-01 20:12:07 UTC
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.

Comment 6 Andrey Ivanov 2010-02-01 20:15:21 UTC
An important note: the syntax validation errors reported above (cn=config & o=NetscapeRoot)are all generated with

nsslapd-dn-validate-strict: off

Comment 7 Rich Megginson 2010-02-01 20:21:34 UTC
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);

Comment 8 Noriko Hosoi 2010-02-01 21:02:28 UTC
(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);

Comment 9 Noriko Hosoi 2010-02-01 21:26:50 UTC
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.

Comment 10 Noriko Hosoi 2010-02-01 21:43:07 UTC
(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

Comment 11 Noriko Hosoi 2010-02-01 21:57:13 UTC
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

Comment 12 Noriko Hosoi 2011-03-29 22:17:38 UTC
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.

Comment 13 Andrey Ivanov 2011-03-30 06:58:51 UTC
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...

Comment 14 Noriko Hosoi 2011-03-30 17:37:49 UTC
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

Comment 15 Amita Sharma 2011-08-01 12:03:08 UTC
[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.


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