ca-add: fix permission issue

[frasertweedale]

The ca-add command pre_callback uses ldap.can_add() to check whether
the user has permission to add CAs. Alas, the GetEffectiveRights
control used by ldap.can_add() doesn't correctly interpret ACIs with
'targetfilter' constraints, and returns a false-negative for
non-admin users, even when they have the 'System: Add CA'
permission.

To work around this, add the CA object to FreeIPA before attempting
to create the CA in Dogtag. If the CA creation in Dogtag succeds,
the user then updates the FreeIPA object with the Authority ID and
other authoritative data returned by Dogtag. If the CA creation in
Dogtag fails, the user cleans up by deleting the newly-created CA
object from FreeIPA.

This modified procedure ensures that the user certainly has the
'System: Add CA' permission before the CA creation in Dogtag is
attempted. But it also means that the user must have 'write' and
'delete' permission on 'ipaca' objects in FreeIPA, so that it can
complete the object after CA creation in Dogtag, or clean up if that
step fails. Therefore, update the 'System: Add CA' permission to
confer 'write' and 'delete' access on 'ipaca' objects, as well as
'add' access.

Fixes: https://pagure.io/freeipa/issue/6609

[rcritten]

Is there a bug filed on the GER issue?

[frasertweedale]

@rcritten yes: https://pagure.io/389-ds-base/issue/49278

[rcritten]

Ok cool. I shouldn't have been so terse in my previous comment, what I should have added was "does it make sense to include a pointer to the bug as a hint so workaround can be removed some time in the future?"

This PR is sort of a brute-force solution but given the infrequency it will be executed it seems perfectly reasonable.

[frasertweedale]

On Thu, Jun 01, 2017 at 06:55:59AM -0700, Rob Crittenden wrote: Ok cool. I shouldn't have been so terse in my previous comment, what I should have added was "does it make sense to include a pointer to the bug as a hint so workaround can be removed some time in the future?" This PR is sort of a brute-force solution but given the infrequency it will be executed it seems perfectly reasonable.

Good idea; I'll add a link to the bug in the patch itself.

[rcritten]

Reading this again it makes me wonder. Which is worse?

• Allowing entries to be written and deleted in an Add ACI?
• Dropping the targetfilter to relax why kind of object is writeable in the container?

The first would purposely combine the Add, Delete and Write ACI's into one which could confuse users who really want atomic rights.

[frasertweedale]

@rcritten neither is desirable; this is just a workaround until the issue gets fixed in DS,
after all ;)

[rcritten]

Elsewhere in the framework we just let the add fail rather than using GER to check in advance. What is the benefit of using GER in this case rather than just letting the add fail?

[frasertweedale]

@rcritten the benefit of GER (if it worked the way we want) is that it would allow us to:

1. check rights
2. create LWCA in Dogtag
3. add CA object in IPA (and the Add CA permission would not need to also imply write and delete)

instead of the procedure implemented in this commit:

1. add CA object in IPA
2. create LWCA in Dogtag
3. modify CA object in IPA (add authority ID) or delete it if LWCA creation failed

The latter procedure (which this commit implements) is messier and requires the Add CA permission to grant more privileges than the name suggests.

[rcritten]

I guess what I don't understand are the possible reasons creating the LWCA in dogtag would fail.

[frasertweedale]

There aren't too many - database error, direct database manipulation, or direct action against dogtag to e.g. delete or disable the issuing CA would be the main reasons.

But ignoring deletion, there is still the need to modify the IPA entry to add the authority ID, as part of the normal procedure when creation is successful.

[tiran]

@frasertweedale We had some issues with Travis CI recently. Please rebase on master to fix Travis tests.

[frasertweedale]

The 389ds fix seems to have landed. I'll test it; this patch may be needed no longer.

[frasertweedale]

Seems that there are still issue in 389. Hopefully they will be fixed soon...
https://pagure.io/389-ds-base/issue/49278#comment-491731

[frasertweedale]

The 389ds fix does work, I just wasn't using it right :)

Closing this PR and I'll have a new one soon with changes to make can_add work properly.