[Freeipa-devel] Managed permission versioning

Simo Sorce simo at redhat.com
Thu Apr 17 18:50:29 UTC 2014

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 ?


Simo Sorce * Red Hat, Inc * New York

More information about the Freeipa-devel mailing list