Bug 437900 - Core schema does not match current RFCs
Core schema does not match current RFCs
Status: CLOSED CURRENTRELEASE
Product: Red Hat Directory Server
Classification: Red Hat
Component: Directory Server (Show other bugs)
7.1
All Other
high Severity medium
: DS8.2
: ---
Assigned To: Nathan Kinder
Chandrasekar Kannan
ftp://ftp.rfc-editor.org/in-notes/rfc...
:
Depends On:
Blocks: 434915 FDS1.2.0
  Show dependency treegraph
 
Reported: 2008-03-17 20:02 EDT by Bob Joslin
Modified: 2015-01-04 18:31 EST (History)
6 users (show)

See Also:
Fixed In Version: 8.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-29 19:03:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
CVS Diffs (3.07 KB, patch)
2009-01-12 16:51 EST, Nathan Kinder
no flags Details | Diff

  None (edit)
Description Bob Joslin 2008-03-17 20:02:07 EDT
Description of problem:

A number of schema elements defined in the core directory server schema do not 
match the defintions established by the RFC standards.   It appears when the 
orignal schema was created, there was a lack of clarity.  As a start, the 
following objectclasses in RFC4524 are not defined correctly:

domainRelatedObject
simpleSecurityObject
Comment 1 Bob Joslin 2008-03-18 14:39:02 EDT
From RFC4524 the following objectclasses are not defined correctly:

cRLDistributionPoint

Note that much of 4524 is not established in the product schema.
Comment 2 Bob Joslin 2008-03-18 18:09:04 EDT
(In reply to comment #1)
> From RFC4524 the following objectclasses are not defined correctly:
> cRLDistributionPoint
> Note that much of 4524 is not established in the product schema.

Note that the above thet should have referred to RFC4523, not 4524.
Comment 4 Nathan Kinder 2009-01-12 14:14:45 EST
We do not want to make any potentially invasive modifications to any default schema in an update release.  We hope to update most of the standard schema to use the definitions from the most recent RFCs in the 9.0 release.

Is there a smaller specific issue that you would like addressed in 8.1 related to the schema you referenced above?  The only difference I notice in the definitions of domainRelatedObject and simpleSecurityObject between DS and RFC4524 is that the RFC has the AUXILIARY keyword present.  Is this causing a problem that requires this to be addressed in DS 8.1?
Comment 5 Bob Joslin 2009-01-12 14:27:54 EST
Yes, simpleSecurityObject and domainReleatedObject are particular problems for an application I am working on.  It would be nice if these two could be set as AUXILIARY, as is mentioned in the schema, but I understand if this is considered to risky of a change at this time, though I kind of doubt there are users of this schema that are relying on it being structural.
Comment 6 Nathan Kinder 2009-01-12 14:57:22 EST
I think it is safe to add the AUXILIARY keyword to these two definitions.  I would like to hold off on other updates until 9.0.  I'll open a new bug for the more major update and use this bug for simpleSecurityObject and domainReleatedObject.
Comment 7 Nathan Kinder 2009-01-12 16:20:37 EST
Opened bug 479753 to deal with updating core schema to match the current RFCs in the 9.0 version.
Comment 8 Nathan Kinder 2009-01-12 16:51:27 EST
Created attachment 328793 [details]
CVS Diffs

This adds the AUXILIARY keyword to the definitions of the domainRelatedObject and simpleSecurityObject objectclasses.
Comment 9 Nathan Kinder 2009-01-12 18:50:18 EST
Checked into ldapserver (HEAD).  Thanks to Noriko for her review!

Checking in ldap/schema/28pilot.ldif;
/cvs/dirsec/ldapserver/ldap/schema/28pilot.ldif,v  <--  28pilot.ldif
new revision: 1.5; previous revision: 1.4
done
Comment 10 Jenny Galipeau 2009-02-27 07:57:09 EST
Please add steps to verify.  Currently:

[root@dhcp-100-2-17 schema]# cat *.ldif | grep simpleSecurityObject
objectClasses: ( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject' DESC 'Standard LDAP objectclass' SUP top AUXILIARY MUST ( userPassword ) X-ORIGIN 'RFC 1274' )
[root@dhcp-100-2-17 schema]# cat *.ldif | grep domainReleatedObject
[root@dhcp-100-2-17 schema]#
Comment 11 Nathan Kinder 2009-02-27 14:05:09 EST
The simpleSecurityDefinition looks good.  You should just be looking for the "AUXILIARY" keyword to be present.

Your grep for domainRelatedObject has a type in it, but you should find that it also has the "AUXILIARY" keyword present in it's definition.
Comment 12 Jenny Galipeau 2009-02-27 14:09:38 EST
d'oh

[root@dhcp-100-2-17 schema]# cat *.ldif | grep domainRelatedObject
objectClasses: ( 0.9.2342.19200300.100.4.17 NAME 'domainRelatedObject' DESC 'Standard LDAP objectclass' SUP top AUXILIARY MUST ( associatedDomain ) X-ORIGIN 'RFC 1274' )


Fix verified - RHEL5 DS 8.1
Comment 13 Jeff Bastian 2009-03-26 16:04:19 EDT
Another possible problem is with homeTelephoneNumber and homePhone attributes.

RFC 1274 defines the homeTelephoneNumber attribute:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
9.3.16.  Home Telephone Number

   The Home Telephone Number attribute type specifies a home telephone
   number associated with a person.  Attribute values should follow the
   agreed format for international telephone numbers: i.e., "+44 71 123
   4567".

     homeTelephoneNumber ATTRIBUTE
         WITH ATTRIBUTE-SYNTAX
             telephoneNumberSyntax
     ::= {pilotAttributeType 20}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The OpenLDAP schema defines both attributes:
/etc/openldap/schema/cosine.schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
attributetype ( 0.9.2342.19200300.100.1.20
        NAME ( 'homePhone' 'homeTelephoneNumber' )
        DESC 'RFC1274: home telephone number'
        EQUALITY telephoneNumberMatch
        SUBSTR telephoneNumberSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

But DS 8.0.5-3.el5dsrv only defines homePhone"
/etc/dirsrv/schema/01common.ldif
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
attributeTypes: ( 0.9.2342.19200300.100.1.20 NAME 'homePhone' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 X-ORIGIN 'RFC 1274' )
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Comment 14 Noriko Hosoi 2009-03-26 17:02:02 EDT
(In reply to comment #13)
> Another possible problem is with homeTelephoneNumber and homePhone attributes.
> [...]

Since this is a "verified" bug, I think you'd better open a new bug for the attribute.  The fix would be very simple like this...
cvs diff 01common.ldif
Index: 01common.ldif
===================================================================
RCS file: /cvs/dirsec/ldapserver/ldap/schema/01common.ldif,v
retrieving revision 1.4
diff -r1.4 01common.ldif
99c99
< attributeTypes: ( 0.9.2342.19200300.100.1.20 NAME 'homePhone' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 X-ORIGIN 'RFC 1274' )
---
> attributeTypes: ( 0.9.2342.19200300.100.1.20 NAME ( 'homePhone' 'homeTelephoneNumber' ) DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 X-ORIGIN 'RFC 1274' )
Comment 15 Jeff Bastian 2009-03-27 09:16:53 EDT
(In reply to comment #14)
> Since this is a "verified" bug, I think you'd better open a new bug for the
> attribute. 

See bug 492562
Comment 16 Chandrasekar Kannan 2009-04-29 19:03:12 EDT
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

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