[Freeipa-devel] Managed permission versioning

[Rob Crittenden]

Simo Sorce wrote:
> On Thu, 2014-04-17 at 18:25 -0400, Rob Crittenden wrote:
>> Simo Sorce wrote:
>>> On Thu, 2014-04-17 at 15:00 -0400, Rob Crittenden wrote:
>>>> Simo Sorce wrote:
>>>>> On Thu, 2014-04-17 at 15:48 +0200, Martin Kosek wrote:
>>>>>> I would like to discuss more on the managed read permissions upgrades [1].
>>>>>> Right now, we simply merge an old permission with the new one, making sure that
>>>>>> we only add new attributes instead of just replacing them, to prevent a managed
>>>>>> permission to be spoiled by a lower FreeIPA server version which runs an updates.
>>>>>>
>>>>>> I was thinking about it some more and seems to me we could run in problems when
>>>>>> we for example find out that some permission is too relaxed and we want to
>>>>>> remove some default attribute. Or when we want to update the permission filter.
>>>>>> Or when object has anonymous and authenticated permission and we want to move
>>>>>> attribute from anonymous to authenticated permission.
>>>>>>
>>>>>> Changes like this can happen, especially in the first release and we do not
>>>>>> have means to address them. What about simply versioning the permissions as we
>>>>>> do with our configs? I.e.
>>>>>>
>>>>>> 1) Introduce new MUST numeric attribute ipaPermVersion
>>>>>> 2) Add 'version' field to managed permissions:
>>>>>>
>>>>>>        managed_permissions = {
>>>>>>            'System: Read Roles': {
>>>>>>                'version': 1,
>>>>>>                'replaces_global_anonymous_aci': True,
>>>>>>                'ipapermbindruletype': 'permission',
>>>>>>                'ipapermright': {'read', 'search', 'compare'},
>>>>>>                'ipapermdefaultattr': {
>>>>>>                    'businesscategory', 'cn', 'description', 'member', 'memberof',
>>>>>>                    'o', 'objectclass', 'ou', 'owner', 'seealso',
>>>>>>                },
>>>>>>                'default_privileges': {'RBAC Readers'},
>>>>>>            },
>>>>>>        }
>>>>>> 3) Modify updater to only update the permission if it's version is higher than
>>>>>> the one in LDAP. In that case, it should simply replace the managed permission
>>>>>> attributes with the new one, no merging (except the attributes that we allow
>>>>>> users to change).
>>>>>>
>>>>>> When we want to change the permission, we simply do the changes, bump the
>>>>>> version and we are done and we do not need to fear some older FreeIPA will
>>>>>> overwrite it. That of course assumes that the versioning would be available
>>>>>> from FreeIPA 4.0.
>>>>>>
>>>>>> Makes sense?
>>>>>>
>>>>>> [1] http://www.freeipa.org/page/V3/Managed_Read_permissions
>>>>>
>>>>>
>>>>> Uhmm, yes, and no, let me explain.
>>>>>
>>>>> What you say *does* make sense, but you are being too focused :-)
>>>>> The upgrade issue is not limited to permissions, but affects everything.
>>>>>
>>>>> I think that what we need is to add a "ipa schema version" attribute
>>>>> somewhere in cn=etc, and then always check this number in the updater
>>>>> script. if this number is higher than what we know we immediately stop
>>>>> and do not perform updates that affect anything but our own server data.
>>>>>
>>>>> This will protect the whole tree from unintentional changes caused by an
>>>>> older replica.
>>>>>
>>>>> Makes sense ?
>>>>
>>>> This could lead to new features not working. Those features would rely
>>>> on containers, ACIs, etc to exist but they wouldn't if the updates
>>>> aren't run.
>>>
>>> Sorry I don't get this, if they are new features, then the version will
>>> be "older" and the update *will* run and at the end raise the version.
>>>
>>> We just prevent old updates from running and current updates from
>>> running multiple times, for the shared tree.
>>>
>>> Do we depend on having updates run multiple times for the data in the
>>> shared tree ?
>>>
>>> Note that I am not saying that all updates should stop, any update for
>>> cn=config would still need to be run on each server (although setting a
>>> version there too would probably be beneficial).
>>
>> Ok, so the update runs, adds data, which gets replicated out to
>> potentially old servers, and we're at the place you said we wouldn't be.
>
> I am not following you, the aim here is not to avoid replicating new
> data to old server, the aim is that if you update the rpm of an older
> replica and the rpm runs the ldap updater with the *old* code, we do not
> end up with that updater *undoing* what a more recent update did.
>
>> Updates are all loaded and sorted so that all changes to a given DN
>> should be applied at once, so it isn't like applying a old update and a
>> new update are two separate operations. In fact, it would likely be a
>> no-op in the case that they have already been applied.
>>
>> Do you have any examples to clarify your concerns? I'm not following you.
>
> Sure at some point version freeipa version 4.2 is released and it has an
> update that changes a default object so that now attribute 'foo' is
> added, this is done through the updater.
>
> Later on we release freeipa version 5.0 and we realize we will have
> again to remove attribute 'foo' because we never really needed it, plus
> if it is still there it causes issues to new feature XYZ.
>
> The admin installs 5.0 and all are happy, then a week later he runs a
> simply yum update on th eolder replicas still running 4.2 and 4.2.1 is
> available, and gets installed and ... bah the 4.2.1 updater re-adds
> attribute 'foo' back ... and 5.0 servers are now broken.
>
> If we have an updater version field when the 4.2.1 update goes on it
> will see that all updates that were necessary (and more) have already
> been added and just quits.

Ok, this won't happen in a modify case. When changing data we only 
change a known existing value, so exact match is required.

The only risk is in adding and deleting data.

So if we delete a permission named "Do cool stuff" in 5.0 and that was 
something previously added in 4.2 then yeah, re-running the 4.2 updates 
will re-apply the data. Similarly deletes would always be applied.

I would not be keen on adding a global version value though, as we've 
had issues with updates in the past where re-running the updater would 
fix things. This would short circuit that.

Something more fine-grained might work but carries its own problems.

rob