As many have mentioned, this is a problem not just with creatorsName and modifiersName, but with any attribute of syntax DN (members of a group) or any attribute which contains a field of type DN (Access Control Items, ACIs [ACIs as an attribute are not defined, and in fact are implementation specific]).
I think referential integrity definitely affects interoperability--especially when access control is considered. Let me give an example.
Step 1. User John Smith, "cn=jsmith, ou=abc, o=def, c=us" is a vice president and consequently is a member of several groups that give him the right to see financial reports, etc. ("cn=jsmith, ..." is in the member attribute of the groups and the groups are named in various ACIs). He is also given explicit rights in the tree ("cn=jsmith, ..." is named in various ACIs).
Step 2. John Smith leaves o=def to pursue whatever. His object is deleted.
Step 3. Jack Smith is hired as a mail room clerk. He is created as object "cn=jsmith, ou=abc, o=def, c=us" (the same DN).
Case 1: no referential integrity. DN Attributes are left dangling (pointing to non-existent objects). This case makes assumptions about how the DN is stored.
Because the names in the groups and ACIs for John Smith were left dangling, and Jack Smith now has what used to be John Smiths DN, it appears to the system that Jack Smith is a member of the groups and is listed explicitly in ACIs. Thus a mail room clerk has access to confidential financial documents and can manipulate the tree.
Case 2: referential integrity. DN attributes pointing to non-existent objects are removed by the implementation. Attributes with DN fields that point to non-existent attributes are removed by the implementation.
Thus the implementation deletes all references to "cn=jsmith, ..." when his object is deleted.
Now when Jack Smith is added using the same DN there is no confusion of access control.
My Conclusions:
By not specifying what standard actions should be taken, interoperability has definitely been impaired. Thus this needs to be discussed and standard actions should be included in updates to RFC 2252.
Thoughts?
--the walrus
a.k.a. Brian Jarvis
bjarvis@novell.com
>>> Mark C Smith <mcs@netscape.com> 11/4/1999 11:43:31 >>>
Brian Jarvis wrote:
>
> RFC 2252, 5.1 Defines some standard operational attributes. Among them are
> creatorsName and modifiersName, both syntax DN. If the object listed as a
> creator or modifier is deleted, what should happen to the creatorsName and
> modifiersName attributes that refer to it?
>
> My best guess is that the creatorsName and modifiersName attributes should be
> removed, leaving the object without those standard operational attributes.
I don't think the standards (X.500 or LDAP RFCs) say you should remove
the attributes. I think this choice is best left up to implementations
and ideally to administrators of a given directory service
installation. If someone can make an argument that by not specifying a
standard behavior, interoperability might be impaired, then we should
discuss this further and specify a behavior in the inevitable update to
RFC 2252.
--
Mark Smith
iPlanet Directory Architect / Sun-Netscape Alliance
My words are my own, not my employer's. Got LDAP?
|
As many have mentioned, this is a problem not just with creatorsName and
modifiersName, but with any attribute of syntax DN (members of a group) or any
attribute which contains a field of type DN (Access Control Items, ACIs [ACIs as
an attribute are not defined, and in fact are implementation specific]).
I think referential integrity definitely affects
interoperability--especially when access control is considered. Let me
give an example.
Step 1. User John Smith, "cn=jsmith, ou=abc, o=def, c=us"
is a vice president and consequently is a member of several groups that give him
the right to see financial reports, etc. ("cn=jsmith, ..." is in the
member attribute of the groups and the groups are named in various ACIs).
He is also given explicit rights in the tree ("cn=jsmith, ..." is
named in various ACIs).
Step 2. John Smith leaves o=def to pursue whatever. His object
is deleted.
Step 3. Jack Smith is hired as a mail room clerk. He is created
as object "cn=jsmith, ou=abc, o=def, c=us" (the same DN).
Case 1: no referential integrity. DN Attributes are left dangling (pointing to non-existent objects). This case makes assumptions about how the DN is stored. Because the names in the groups and ACIs for John Smith were left dangling,
and Jack Smith now has what used to be John Smiths DN, it appears to the system
that Jack Smith is a member of the groups and is listed explicitly in
ACIs. Thus a mail room clerk has access to confidential financial
documents and can manipulate the tree.
Case 2: referential integrity. DN attributes pointing to non-existent
objects are removed by the implementation. Attributes with DN fields that
point to non-existent attributes are removed by the implementation.
Thus the implementation deletes all references to "cn=jsmith,
..." when his object is deleted.
Now when Jack Smith is added using the same DN there is no confusion of
access control.
My Conclusions:
By not specifying what standard actions should be taken, interoperability
has definitely been impaired. Thus this needs to be discussed and standard
actions should be included in updates to RFC 2252.
Thoughts?
--the walrus
a.k.a. Brian Jarvis
>>> Mark C Smith <mcs@netscape.com> 11/4/1999 11:43:31
>>>
Brian Jarvis wrote: > > RFC 2252, 5.1 Defines some standard operational attributes. Among them are > creatorsName and modifiersName, both syntax DN. If the object listed as a > creator or modifier is deleted, what should happen to the creatorsName and > modifiersName attributes that refer to it? > > My best guess is that the creatorsName and modifiersName attributes should be > removed, leaving the object without those standard operational attributes. I don't think the standards (X.500 or LDAP RFCs) say you should remove the attributes. I think this choice is best left up to implementations and ideally to administrators of a given directory service installation. If someone can make an argument that by not specifying a standard behavior, interoperability might be impaired, then we should discuss this further and specify a behavior in the inevitable update to RFC 2252. -- Mark Smith iPlanet Directory Architect / Sun-Netscape Alliance My words are my own, not my employer's. Got LDAP? |
BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:Brian Jarvis TEL;WORK:801-861-3856 ORG:;NDS Administration TEL;PREF;FAX:801-861-2292 EMAIL;WORK;PREF;NGW:BJARVIS@novell.com N:Jarvis;Brian TITLE:Engineer ADR;INTL;WORK;PARCEL;POSTAL:;PRV-F221;122 E 1700 S;Provo;UT;84606;USA LABEL;INTL;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Brian Jarvis=0A= PRV-F221=0A= 122 E 1700 S=0A= Provo, UT 84606=0A= USA LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Brian Jarvis=0A= PRV-F221=0A= 122 E 1700 S=0A= Provo, UT 84606 TEL;HOME:801-226-6636 TEL;PREF:801-861-3856 X-GWUSERID:BJARVIS END:VCARD