slapd 2.4.33 changes 'dc' to 'ou' after cn=schema,cn=config modification

[Igor Zinovik <zinovik.igor@gmail.com>]

  Hello.

I'm running openldap 2.4.33 with on-line configuration (slapd-config).  Before
running slapd with on-line configuration i developed my own schema and after
that i converted old fashioned slapd.conf to slapd.d.  Today i modified one
attribute in my schema from this:

olcAttributeTypes: {9}( 2.16.840.1.113730.3.1.217 NAME 'spamassassin' DESC 'Sp
 amAssassin user preferences settings' EQUALITY caseExactMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

to this

olcAttributeTypes: {9}( 2.16.840.1.113730.3.1.217 NAME 'spamassassin' DESC 'Sp
 amAssassin user preferences settings' SUP name )

I was binded to cn=config with DN that is not part of that tree, my dn was
uid=zinovik,ou=people,dc=...,dc=ru

So after that change i noticed that i see following messages while running
slaptest:
ldap1:~ $ sudo slaptest -vF /etc/openldap/slapd.d
51800ba4 PROXIED attributeDescription "OU" inserted.
51800ba4 PROXIED attributeDescription "DC" inserted.
config file testing succeeded

I pointed out that this happened because i modified entries in cn=config with
modifierName not being part of cn=config namespace.

But that is not a problem.  Problem happens when i do following
ldap1:~ $ cat example.com.ldif
dn: dc=example.com,ou=Mail,dc=...,dc=ru
objectClass: top
objectClass: domain
objectClass: amavisAccount
dc: example.com
amavisLocal: TRUE

ldap1:~ $ ldapadd -v -ZZxWD uid=zinovik,ou=people,dc=...,dc=ru -f example.com.ldif
add objectClass:
        top
        domain
        amavisAccount
add dc:
        example.com
add amavisLocal:
        TRUE
adding new entry "dc=example.com,ou=Mail,dc=...,dc=ru"
modify complete

ldap1:~ $ ldapsearch -LLLZZxWD uid=zinovik,ou=people,dc=...,dc=ru -b ou=Mail,dc=...,dc=ru -s one '(&)'
Enter LDAP Password:
dn: dc=example.com,ou=Mail,dc=...,dc=ru
objectClass: top
objectClass: domain
objectClass: amavisAccount
ou: example.com
amavisLocal: TRUE

Why i do not see 'dc' attribute in this entry and why 'ou' appeared?

Trace of this operation:
51800cc6 >>> dnPrettyNormal: <dc=example.com,ou=Mail,dc=...,dc=ru>
51800cc6 <<< dnPrettyNormal: <dc=example.com,ou=Mail,dc=...,dc=ru>, <dc=example.com,ou=mail,dc=...,dc=ru>
51800cc6 ==> unique_add <dc=example.com,ou=Mail,dc=...,dc=ru>
51800cc6 oc_check_required entry (dc=example.com,ou=Mail,dc=...,dc=ru), objectClass "domain"
51800cc6 oc_check_required entry (dc=example.com,ou=Mail,dc=...,dc=ru), objectClass "amavisAccount"
51800cc6 oc_check_allowed type "objectClass"
51800cc6 oc_check_allowed type "dc"
51800cc6 oc_check_allowed type "amavisLocal"
51800cc6 oc_check_allowed type "structuralObjectClass"
51800cc6 mdb_dn2entry("dc=example.com,ou=mail,dc=...,dc=ru")
51800cc6 => mdb_dn2id("dc=example.com,ou=mail,dc=...,dc=ru")
51800cc6 <= mdb_dn2id: get failed: MDB_NOTFOUND: No matching key/data pair found (-30798)
51800cc6 => mdb_entry_decode:
51800cc6 <= mdb_entry_decode
51800cc6 mdb_dn2entry("cn=ldap admins,ou=groups,dc=...,dc=ru")
51800cc6 => mdb_dn2id("cn=ldap admins,ou=groups,dc=...,dc=ru")
51800cc6 <= mdb_dn2id: got id=0xfab
51800cc6 => mdb_entry_decode:
51800cc6 <= mdb_entry_decode
51800cc6 mdb_entry_get: rc=0
51800cc6 => mdb_dn2id_add 0x1f19: "dc=example.com,ou=mail,dc=...,dc=ru"
51800cc6 <= mdb_dn2id_add 0x1f19: 0
51800cc6 => index_entry_add( 7961, "dc=example.com,ou=Mail,dc=...,dc=ru" )
51800cc6 <= index_entry_add( 7961, "dc=example.com,ou=Mail,dc=...,dc=ru" ) success
51800cc6 => mdb_entry_encode(0x00001f19): dc=example.com,ou=Mail,dc=...,dc=ru
51800cc6 <= mdb_entry_encode(0x00001f19): dc=example.com,ou=Mail,dc=...,dc=ru
51800cc6 mdb_add: added id=00001f19 dn="dc=example.com,ou=Mail,dc=...,dc=ru"
51800cc6 send_ldap_result: conn=1000 op=2 p=3


When i try to modify attribute:

dn: dc=example.com,ou=Mail,dc=...,dc=ru
changetype: modify
add: dc
dc: example.com

I get:
modifying entry "dc=example.com,ou=Mail,dc=...,dc=ru"
ldap_modify: Object class violation (65)
        additional info: attribute 'ou' not allowed


Even my root object lost its 'dc' attribute somehow:
ldap1: ~$ ldapsearch -LLLZZxWD uid=zinovik,ou=people,dc=...,dc=ru -b dc=...,dc=ru -s base '(&)'
dn: dc=...,dc=ru
ou: ...
objectClass: organization
objectClass: dcObject
o: my organization

If it matters i use slapd-mdb as storage backend.  I did not changed 'dc' and 'ou':
ldap1:~ $ ldapsearch -LLLZZxWD uid=zinovik,ou=people,dc=...,dc=ru -b 'cn={0}core,cn=schema,cn=config' '(&)' olcAttributeTypes|egrep -e "'(ou|dc)'"
Enter LDAP Password:
olcAttributeTypes: {8}( 2.5.4.11 NAME ( 'ou' 'organizationalUnitName' ) DESC '
olcAttributeTypes: {49}( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domainCompone


I do not use slapo-rwm.  Here are my overlays for dc=...,dc=ru:
dn: olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcMemberOf
olcOverlay: {0}memberof
olcMemberOfDangling: ignore
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: groupOfNames
olcMemberOfMemberAD: member

dn: olcOverlay={1}refint,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcRefintConfig
olcOverlay: {1}refint
olcRefintAttribute: seeAlso
olcRefintAttribute: uniqueMember
olcRefintAttribute: member
olcRefintNothing: cn=EMPTY

dn: olcOverlay={2}unique,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcUniqueConfig
olcOverlay: {2}unique
olcUniqueURI: ldap:///ou=Hosts,dc=...,dc=ru?ipHostNumber?sub
olcUniqueURI: ldap:///ou=People,dc=...,dc=ru?uid,uidNumber?sub
olcUniqueURI: ldap:///ou=Groups,dc=...,dc=ru?cn,gidNumber?sub
olcUniqueURI: ldap:///ou=Mail,dc=...,dc=ru?mail,mailLocalAddress?sub

dn: olcOverlay={3}syncprov,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
olcOverlay: {3}syncprov
olcSpCheckpoint: 200 20
olcSpSessionlog: 100