Bug 445775

Summary: standard schema gets replicated if DESC is empty
Product: Red Hat Directory Server Reporter: Ulf Weltman <ulf.weltman>
Component: Directory ServerAssignee: Nathan Kinder <nkinder>
Status: CLOSED CURRENTRELEASE QA Contact: Chandrasekar Kannan <ckannan>
Severity: medium Docs Contact:
Priority: high    
Version: 8.0CC: benl, jgalipea, nhosoi, nkinder, rmeggins
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: 8.1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-04-29 23:04:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 249650, 493682    
Attachments:
Description Flags
CVS Diffs none

Description Ulf Weltman 2008-05-09 00:55:34 UTC 
If schema looks like this on disk (empty DESC):
objectClasses: ( 2.5.6.0 NAME 'top' DESC '' ABSTRACT MUST objectClass X-ORIGIN '
RFC 2256' )

It looks like this when searched (no DESC keyword):
objectClasses: ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass X-ORIGIN 'RFC 2256' )

This causes a problem during schema replication:
1)
When schema is pushed to a consumer during replication it uses a MOD-REPLACE
operation where each of the master's schema definitions is a value, including
standard its schema.

2)
On the consumer the schema replace operation callback modify_schema_dse() calls
on schema_replace_objectclasses() or schema_replace_attributes().  These will
parse the schema definition from each MOD value into objinfo or asyntaxinfo structs.

3)
Then the consumer looks through existing in-memory definitions to see if any
schema exists with the same OID.  Lots of the incoming schema definitions will
have collisions since both master and consumer should have the same standard
schema files.

4)
For each collision, further checking is performed using oc_equal() or
attr_syntax_equal() to see if they really are identical.  If they are truly
identical, which most of them will be, then we throw that new MOD value out.  If
they don't compare equal then the incoming schema definition will be added on
the consumer.  This would be OK in some cases, it seems we have a half-baked
feature where we can redefine standard schema over the wire.

5)
However, we get an unexpected result here if the DESC is empty; they don't
compare equal because the incoming schema definitions DESC is NULL and the
existing schema definitions DESC is "".  We end up with duplicate definitions,
one in standard schema file and one in user schema file, where the only
difference is that one has empty DESC, and the other has a missing DESC and is
marked user-defined (all incoming schema definitions get marked user-defined).
Comment 1 Nathan Kinder 2008-12-03 00:15:46 UTC 
To reproduce:

  - Setup 2 DS instances and configure them for replication.
  - Add a new custom attribute definition to the first master over LDAP.
  - Add a user entry to the first master (no need to use new schema).

At this point, the 99user.ldif file on the first master should only contain your new attribute definition.  The 99user.ldif file on the second master will contain this new attribute definition as well, but it also contain a number of other default schema definitions having to do with e-mail related objectclasses/attributes.
Comment 2 Nathan Kinder 2008-12-04 21:41:25 UTC 
Created attachment 325750 [details]
CVS Diffs

The fix is to ensure that we list an empty DESC element in the LDAP entry representation of the schema when searching for it if that is the way it is defined on disk.
Comment 3 Nathan Kinder 2008-12-04 22:33:58 UTC 
Checked into ldapserver (HEAD).  Thanks to Noriko for her review!

Checking in ldap/servers/slapd/schema.c;
/cvs/dirsec/ldapserver/ldap/servers/slapd/schema.c,v  <--  schema.c
new revision: 1.18; previous revision: 1.17
done
Comment 4 Jenny Severance 2009-03-17 19:16:37 UTC 
If I am correct in interpreting this bug:  I should see an empty DESC element in the LDAP entry when searching the schema - I don't see this:

attributeTypes: ( mytestattribute-oid NAME 'mytestattribute'  SYNTAX 1.3.6.1.4
 .1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' )

99user.ldif:

attributeTypes: ( mytestattribute-oid NAME 'mytestattribute'  SYNTAX 1.3.6.1.4
 .1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' )
nsSchemaCSN: 49bfae6a000000000000

Both replicas are the same.

Is this correct?
Comment 5 Nathan Kinder 2009-03-17 19:26:47 UTC 
(In reply to comment #4)
> If I am correct in interpreting this bug:  I should see an empty DESC element
> in the LDAP entry when searching the schema - I don't see this:
> 
> attributeTypes: ( mytestattribute-oid NAME 'mytestattribute'  SYNTAX 1.3.6.1.4
>  .1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' )
> 
> 99user.ldif:
> 
> attributeTypes: ( mytestattribute-oid NAME 'mytestattribute'  SYNTAX 1.3.6.1.4
>  .1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' )
> nsSchemaCSN: 49bfae6a000000000000
> 
> Both replicas are the same.
> 
> Is this correct?  

Yes, this looks correct as long as no other standard schema magically appeared in either 99user.ldif.

The problem was that some standard schema had empty descriptions, which would cause those definitions to get replicated into the other masters 99user.ldif.
Comment 6 Jenny Severance 2009-03-17 20:03:35 UTC 
verified RHEL 5 <--> RHEL 4 DS 8.1
Comment 7 Chandrasekar Kannan 2009-04-29 23:04:00 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-0455.html