Date: | Thu, 27 Sep 2012 11:26:26 -0500 |
Subject: | Policy deletion should not rely in refcounts |
From: | Nico Williams <nico@cryptonector.com> |
To: | krb5-bugs@mit.edu |
Besides rt #7384, I've seen other policy refcount bugs in MIT Kerberos before.
It seems to me that it'd be better to not rely on the refcounts in the policy
DB. Instead we should consider any of these approaches to handling policy
deletion:
- disallow policy deletion
- iterate all principals at policy deletion time and apply any of cascade,
null (change to default policy), or restrict referential integrity rules
- delete without checking and allow dangling references to non-existent
policies (somewhat like an implied referential integrity rule that
nulls policy references)
We may well need to be able to handle principals that refer to non-existent
policies for the simple reason that there may be such principals in some
existing KDBs. This makes the third choice above tempting, but it does
not preclude either of the others.
My proposal is the second of the above, with "restrict" rules.
It seems to me that it'd be better to not rely on the refcounts in the policy
DB. Instead we should consider any of these approaches to handling policy
deletion:
- disallow policy deletion
- iterate all principals at policy deletion time and apply any of cascade,
null (change to default policy), or restrict referential integrity rules
- delete without checking and allow dangling references to non-existent
policies (somewhat like an implied referential integrity rule that
nulls policy references)
We may well need to be able to handle principals that refer to non-existent
policies for the simple reason that there may be such principals in some
existing KDBs. This makes the third choice above tempting, but it does
not preclude either of the others.
My proposal is the second of the above, with "restrict" rules.