Options for dealing with LDAP policy refcounts

[Nicolas Williams]

On Thu, Oct 07, 2010 at 12:42:19PM -0400, ghudson at MIT.EDU wrote:
> My immediate reaction was that the refcount should be treated as an
> implementation detail of the DB module.  Unfortunately, that doesn't
> pan out as easily as I thought; it would require DB2's put_principal
> method to become much more complicated.

Mine too.

> I can see two options:
> 
> 1. The LDAP back end sets the policy refcount to 0, so
> kadm5_delete_policy() never fails the refcount check.  LDAP's
> delete_policy operation performs the subtree scan and returns a new
> KDB error (which libkadm5srv would translate to KADM5_POLICY_REF) if
> any principals reference the policy.
> 
> 2. Stop using the refcount field entirely.  If you delete a policy
> with principals referencing it, those principals become policy orphans
> and behave as if they had no policy.

Both have the same effect of not restricting deletion of policies that
have principals referring to them.  But the second option allows the
backend to refuse to delete a policy.  For example, the LDAP DS could
fail a policy object deletion with constraintViolation,
unwillingToPerform, other, or even some extended value of LDAPResult.

Given that I prefer the second option as it is more general.  And for
the same reasons that you give:

> I like the second option because it lets us remove a bunch of code,
> and because deleting password policies strikes me as a rare operation
> which doesn't need a strong safety guarantee.  The first option is a
> more conservative response, though.

I don't think that the first option is more conservative _unless_ you
fail to add the referential integrity code into the db2 KDB backend.
But I'd be OK with that too.

Nico
--