Allow renaming of sudo and HBAC rules

[stlaz]

This simple hack adds a rename option to client side sudorule-mod
command.

https://pagure.io/freeipa/issue/2466

[abbra]

I don't like it is done on the client side. This will not work for Web UI, for example.
Additionally, no validation of cn={newname} is here to be a single value RDN. If we add this as --setattr, we probably want to return meaningful error, not a general --setattr error.

[stlaz]

Thank you Alexander for your insight. Since this was a hack, I did not want to do it server-wise. I chose a different approach to the problem and reworked the original idea so the rename option is now worked with on server.
With this approach, we are able to white-list objects which we think may be allowed renaming even though their primary keys are not in their RDN.

Just for the record, the names of sudo rules are still not checked for CN compatibility since their primary key is not part of their DN, but that's how things have been since for ever, I am afraid (you can try ipa sudorule-add bad,cn=rule).

[HonzaCholasta]

Why introduce a new class attribute when rdn_is_primary_key does exactly the same?

[stlaz]

Because we want to rename objects whose primary key is not RDN. But you're right, perhaps the attribute is just ill-named.

edit: nope, we are not changing DN in these objects.

[HonzaCholasta]

IMO the attribute is entirely ill, as it does 2 different things: it allows renaming and forces DN update on rename.

I think we should finally get rid of it and use

• the allow_rename attribute to allow renaming and
• decide whether a DN update is required or not based on the current DN.

[HonzaCholasta]

Note that the above should be done in a separate commit and linked to https://pagure.io/freeipa/issue/2466.

[abbra]

I like the idea but please address @HonzaCholasta comments.

[stlaz]

For the record, and I might be wrong, I did a bit of researching, the rdn_is_primary_key is actually misused in some cases, as RDN is the primary key for e.g. pwpolicy and idrange but these have this attribute set to False.
I believe in the above cases, rdn_is_primary_key might have been used this way just so that those objects do not show the rename (they are not allowed to change the primary key anyway). I thought we won't need allow_rename at all in the end but for these cases we will probably need to keep it.

[stlaz]

The latest patch removes the rdn_is_private_key attribute, replaces it with allow_rename which actually says correctly what's happening. Also, the decision whether primary key is in RDN is decided on checking whether the primary key is in RDN rather than on anything else.
Also added a comment explaining that the modrdn operation is performed also when setattr is doing changes to the primary key + RDN because it was far from obvious in the code.

[MartinBasti]

I'd like to see this in 3 different patches: needed refactoring, sudo, hbac

[MartinBasti]

I like the allow_rename attribute, as it really explains what is happaning, Also I like the reworked check if primary key is in DN because original self.obj.primary_key.name in entry_attrs may return false positive results.

I'm afraid about one thing. This will basically break custom user plugins if they used rdn_is_private_key. Shall we do some backward compatibility magic?

[abbra]

I haven't seen any custom plugin that used rdn_is_private_key. We can document the change in release notes.

[MartinBasti]

Please provide tests, LGTM otherwise

[stlaz]

Added the tests but did not test them so we may want to see what Travis has to say about that.

[MartinBasti]

************* Module ipatests.test_xmlrpc.test_sudorule_plugin
ipatests/test_xmlrpc/test_sudorule_plugin.py:786: [E0001(syntax-error), ] unindent does not match any outer indentation level)

And please split it into multiple commits as I requested

[stlaz]

*sigh* there was a rogue space.

Split into three separate commits.

[MartinBasti]

Please update release notes (changelog)

[stlaz]

Changelogs were updated.

[pvomacka]

ipa-4-5:

• 28db6cd Reworked the renaming mechanism

• 85f2a19 Allow renaming of the HBAC rule objects

• 7d3229b Allow renaming of the sudorule objects
  master:

• 8e4408e Reworked the renaming mechanism

• 55424c8 Allow renaming of the HBAC rule objects

• 8c14091 Allow renaming of the sudorule objects