Subject: Transactional issues with the LDAP Core Schema

From: [email-masked]
Date: Fri, 4 Jun 1999 11:09:34 -0400

Dave,

You wrote the following in a response to Raju:

[[Dave]]  Getting the full LDAP object is not the problem, it
     is the solution. My complaint is that when you go beyond a single
     LDAP entry to express a policy, then you are effectively opening
     up LDAP's non-transactional Achilles heel. Keeping all ANDed
     conditions within a single entry will help prevent clients from
     retrieving incomplete (=incorrect) policies. Attaching conditions
     as separate sibling entries to a policy rule implies that a client
     can retrieve a portion of the DIT that a console is in the process
     of editing. Rules need to be built from the conditions and actions
     up, or entries need to contain all attributes applicable to a rule,
     so that PDPs do not get incorrect policies. Basically, the core
     schema should be designed to take advantage of atomic transactions
     within an entry where LDAP does have limited transactional support.
     The DNF form of complex policy rules violates this principle as
     do simple policy rules (and correct me if I am wrong) where
     conditions and actions are attached as sibling entries.

     I have a host of other transactional issues with using auxiliary
     attachments as labels which will have to be edited across DNs all
     the while PDPs (and other consoles) are potentially querying
     (and editing) the DIT!

While I understand the general point about LDAP's transactional
weakness and the resulting exposure arising from the use of multiple
entries to store related pieces of information, I'm having a hard time
finding the exposures in the specific case of the Core Policy Schema
classes.

For example, there's no chance for a client to get a "half-baked"
policy rule if the entries that make up the rule are added to the
directory (or, if they're already there, updated to say the right
thing) in the following order:

1. Entries like Lee's addressRange object, that are pointed to by
   policy condition and/or policy action objects.
2. All policyCondition and policyAction entries that the policyRule
   will point to.
3. The policyRule entry itself.

It makes no difference whether the rule combines the conditions in DNF
or CNF, since by the time the rule is there to be retrieved, all the
conditions are already present in the directory.

Ordinarily this sequence of updates isn't something that the directory
administrator will need to worry about:  the Policy Tool should take
care of it automatically.  The standard should probably contain an
implementation note saying that a Policy Tool needs to write rule-
related information to the directory in this order, to avoid the
transactional pitfalls that Dave is worried about.

Another set of semantic relationships (besides those between a rule
and its conditions and actions) in the Core Schema are those between
a policy group and the policy rules or policy groups that it
aggregates.  Once again I don't see how a client can be misled if the
order of creation (or update) for these entries is:

1. All the policyRules or policyGroups to be aggregated.
2. The policyGroup instance that aggregates them.

The jurisdiction associations, realized by attaching the policy rule
or policy group pointers to something other than policyGroups, will
work in the same way:  first create the rules / groups being pointed
to, then create the pointers to them.  A client may come to the
directory before this process has been completed, in which case it
will fail to find any of its policy rules.  But this is the same
thing that would happen if it came to the directory before any of
the updates related to its policy rules had been done.  There is, once
again, no point in time when a client might retrieve some of the rules
related to its jurisdiction, while believing that it had retrieved all
of them.

The one case that does strike me as problematic is where a client
is retrieving all the policy rules whose priorities need to be
compared against each other to decide what to do in a particular set
of circumstances.  If the client gets to these rules via a policyGroup,
then there shouldn't be a problem.  The client will know that it's in
the middle of retrieving a set of rules, and so it knows that it must
not do a priority comparison until it finishes retrieving all the
rules.  (The preceding sentence becomes more complicated if we factor
in a PDP / PEP split, but I think the principle still applies.)

Where a client can't be sure it's gotten a complete picture is when
the policy rules whose priorities compete against each other are
identified only by a keyword.  In this case an unlucky client might
search a portion of the DIT for policy rules containing the keyword,
and get back only a partial set of rules, because it happened to do
the search while the rules were being added to the directory.

In this case, if the Policy Tool adds the rules to the directory in
order of decreasing priority, the likelihood of a mishap can be
reduced.  It isn't eliminated completely, though, because of the
following possible sequence of events:

1. The client searches the portion of the DIT that will contain the
   highest priority rule, and it finds nothing.
2. The Policy Tool adds the highest priority rule to the portion of
   the DIT that the client just searched.
3. The Policy Tool adds a lower priority rule to a different portion
   of the DIT.
4. The client searches this second portion of the DIT, and finds the
   lower priority rule.

At this point the client is set up to do the "wrong" thing (i.e., the
action(s) associated with the lower priority rule) if it's
presented with a stimulus that satisfies the conditions of both rules.
Notice, though, that this has nothing to do with splitting a single
policy rule into rule, condition, and action entries.  Exactly the
same thing could happen if each rule were represented by a single
entry.  I understand that Raju has raised some additional questions /
concerns related to prioritization of policy rules.  As we address
these concerns, we should also consider how to insure that a client
doesn't do a priority comparison when it has retrieved only a subset
of the rules that belong in the set to be compared.

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
[email-masked]

---

From: "Durham, David" <[email-masked]>
Date: Fri, 4 Jun 1999 13:36:47 -0700

Thanks Bob, this helps clear things up a bit with my second
example. I see that by following a well-defined procedure 
a policy editor tool can enter policy in a way that will 
avoid many of the "half-baked" policy problems despite the lack 
of transactions. This information should probably find its 
way into the specification because policy editors that do 
not follow the "correct" procedure will create problems.
It would be even better if the LDAPized core schema could
somehow force the correct procedure. 

I still think the issue remains for policies that already 
exist but are instead being edited/updated. Let me see if 
I can conjure up an illustrative example for such a case...
Say, policy "re-ordering" in the case rules are prioritied, 
or redefining two groups already ANDed together within a 
policy rule. Seems as if even more restrictions will have
to be placed on the policy editor for cases as these where
dependencies cross the boundaries of a single entry.

Also, can you explain if there is a procedure for modifying 
auxiliary attachments that act as labels (e.g. through
the policyKeywords attribute) such that lack of transactional
support is not a pitfall here?

-Dave

> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Friday, June 04, 1999 8:10 AM
> To:	[email-masked]
> Cc:	Durham, David; 'Raju Rajan'
> Subject:	Transactional issues with the LDAP Core Schema
> 
> 
> 
> Dave,
>