Subject: Re: creatorsName/modifiersName referential integrity

From: "Brian Jarvis" <[email-masked]>
Date: Fri, 05 Nov 1999 15:03:15 -0700

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
[email-masked]

>>> Mark C Smith <[email-masked]> 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?

---

From: "Howard Chu" <[email-masked]>
Date: Fri, 5 Nov 1999 14:31:03 -0800

> 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 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.
>
> 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?

Referential integrity is easy enough to handle within the bounds of a single
DSA, but it becomes much more interesting in the context of multiple DSAs
with cross-realm references. This is one of the things that the DCE guys got
right, and the X.500 guys in general have already made a lot of progress on.

There is another solution to your example that doesn't require referential
integrity - use UUIDs. The current NameAndOptionalUID attribute has proper
semantics to prevent any confusion due to deletions and recreations as in
your
scenario. It's not sufficient to solve problems due to renamed entries
though.
(Rather, the definition of the UniqueMemberMatch rule is not good enough.)
To be truly useful this should have been "UIDAndOptionalName" - that would
allow you to locate renamed entries where the UID matches but the DN
doesn't,
and then you could fix the DNs.
  -- Howard Chu, [email-masked]
  Chief Architect, Symas Corp.

---

From: Mark Wahl <[email-masked]>
Date: Fri, 05 Nov 1999 16:54:31 -0600

> 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, ...

If you were using an Access Control system which is based on Distinguished
Names and you were allowing for reuse of Distinguished Names, then you could
use the DN and optional Unique Identifier capability of X.500's access control
framework (and others).  By including a unique identifier assigned when the
entry was created, then you could ensure that even if the subject DN is reused,
the new subject would not take on the rights of the previous subject. 

> 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.

RFC 2252 only defines the attributes.  The underlying information model for
LDAP is X.501(1993) and following, which does not define automatic attribute
value deletion.  If there was a desire to standardize on an algorithm for
automatic value deletion, it would be done with an extension specification, so
that an LDAP client could determine whether a server did so, and on what 
subtrees it was in effect. This behavior would augment the behavior of X.511
for performing operations.  

Before however we consider automatic attribute value deletion for 
standardization, I would want to see some consideration of an approach for the 
interaction between servers which do not replicate that information.   This 
could be done in LDAPEXT or more likely in a successor WG to LDAPEXT for 
inter-server issues other than replication (chaining, proxy auth etc).

Mark Wahl, Directory Product Architect
Innosoft International, Inc.