[Freeipa-devel] Ticket #2866 - referential integrity in IPA

[Rich Megginson]

On 08/27/2012 11:12 AM, Rob Crittenden wrote:
> Rich Megginson wrote:
>> On 08/27/2012 06:41 AM, Dmitri Pal wrote:
>>> On 08/17/2012 10:00 AM, Rich Megginson wrote:
>>>> On 08/17/2012 07:44 AM, Martin Kosek wrote:
>>>>> Hi guys,
>>>>>
>>>>> I am now investigating ticket #2866:
>>>>> https://fedorahosted.org/freeipa/ticket/2866
>>>>>
>>>>> And I am thinking about possible solutions for this problem. In a
>>>>> nutshell, we do not properly check referential integrity in some IPA
>>>>> objects where we keep one-way DN references to other objects, e.g. in
>>>>> - managedBy attribute for a host object
>>>>> - memberhost attribute for HBAC rule object
>>>>> - memberuser attribute for user object
>>>>> - memberallowcmd or memberdenycmd for SUDO command object 
>>>>> (reported in
>>>>> #2866)
>>>>> ...
>>>>>
>>>>> Currently, I see 2 approaches to solve this:
>>>>> 1) Add relevant checks to our ipalib plugins where problematic
>>>>> operations with these operations are being executed (like we do for
>>>>> selinuxusermap's seealso attribute in HBAC plugin)
>>>>> This of course would not prevent direct LDAP deletes.
>>>>>
>>>>> 2) Implement a preop DS plugin that would hook to MODRDN and DELETE
>>>>> callbacks and check that this object's DN is not referenced in other
>>>>> objects. And if it does, it would reject such modification. Second
>>>>> option would be to delete the attribute value with now invalid
>>>>> reference. This would be probably  more suitable for example for
>>>>> references to user objects.
>>>>>
>>>>> Any comments to these possible approaches are welcome.
>>>>>
>>>>> Rich, do you think that as an alternative to these 2 approaches,
>>>>> memberOf plugin could be eventually modified to do this task?
>>>> This is very similar to the referential integrity plugin already in
>>>> 389, except instead of cleaning up references to moved and deleted
>>>> entries, you want it to prevent moving or deleting an entry if that
>>>> entry is referenced by the
>>>> managedby/memberhost/memberuser/memberallowcmd/memberdenycmd of some
>>>> other entry.
>>>>
>>>> Note that the managed entry plugin (mep) already handles this for the
>>>> managedby attribute.
>>>>
>>>> Are you already using the memberof plugin for
>>>> memberhost/memberuser/memberallowcmd/memberdenycmd?
>>>>
>>>> This doesn't seem like a job for memberof, this seems like more of a
>>>> new check for the referential integrity plugin.
>>> Did it translate into a DS ticket?
>> No.  Is there an IPA ticket to link to?
>
> Not yet. I wonder if we need to flesh out what this means (and may 
> mean) going forward. Are there any downsides to linking entries in 
> this way.

Performance is one downside.  Although with the work that Noriko is 
doing on transactions, this may not be as big an issue.  SQL databases 
have long supported this sort of referential integrity checking, so it 
makes sense to put this sort of "business logic" in the database.

>
> rob