[Freeipa-devel] [freeipa] #6002: Default CA can be used without an ACL

[Jan Cholasta]

On 19.7.2016 09:01, Fraser Tweedale wrote:
> On Tue, Jul 19, 2016 at 08:26:22AM +0200, Jan Cholasta wrote:
>> Hi,
>>
>> On 4.7.2016 09:06, Fraser Tweedale wrote:
>>> On Tue, Jun 28, 2016 at 01:47:23PM -0000, freeipa wrote:
>>>> #6002: Default CA can be used without an ACL
>>>>
>>>> Comment (by ftweedal):
>>>>
>>>>  This is expected behaviour; if a CA ACL does not reference any CAs,
>>>>  and does not have cacat=all, then it is assumed to refer to the
>>>>  default CA.  This is for backwards compatibility with existing
>>>>  CA ACLs, which do not reference any CAs but did (and still do)
>>>>  allow access to IPA CA.
>>>>
>>>>  Leaving open for discussion about whether to break compatibility
>>>>  for a more consistent behaviour.
>>>>
>>> Didn't get any feedback in the ticket yet so raising on list for
>>> visibility.  If people agree with current behaviour I can add a
>>> clarification to caacl plugin help text and close out this ticket.
>>
>> (Sorry for the late reply, I was on vacation the last 2 weeks.)
>>
>> I would very much prefer if this was consistent with (literally) every other
>> member list+category attribute, that is, no member and no category means the
>> rule never matches.
>>
>> While documenting this as an exception to the above rule is the easy way
>> out, IMHO adhering to the rule is even better - anyone who touched HBAC or
>> sudo in IPA would immediately know their way around CA ACLs without having
>> to read the documentation at all, which is a win, because people don't
>> generally read documentation until something goes wrong. The current
>> behavior might surprise them, even if documented properly (it sure surprised
>> me at first :-).
>>
>> BTW I think this can be done without breaking compatibility, e.g. by using a
>> new objectclass to distinguish between "old" (CA is always implicitly the
>> top-level CA) and "new" (CAs are specified using the member and category
>> attributes) CA ACLs.
>>
>> Honza
>>
> Is there precedent of "varying behaviour based on objectclass" in
> IPA?

Yes, for example in the permission plugin.

>
> Would it go along the lines of...
>
> 1. subtype 'ipaCaAcl' object class (let us call it 'ipaCaAclWithCa'
>    for sake of discussion).  (Note that moving the 'ipaCa' attribute
>    to be part of 'ipaCaAclWithCa' would not be backwards compatible
>    with v4.4 as currently released, so it would remain in 'ipaCaAcl'
>    objectclass.)
>
> 2. Upgrade script to take 'ipaCaAcl' objects that are NOT
>    'ipaCaAclWithCa', and make them so, while adding the IPA CA.
>
> Is this what you have in mind?

Yes, something like this, but we can't inherit the new object class from 
ipaCaAcl if we want "new" CA ACLs to be invisible on 4.3 servers.

>
> If so, I don't think there is actually a need to vary the behaviour
> based on object class, other than during upgrade.  The reason I was
> not doing upgrades in the first place was because I could not in
> distinguish between "old" CA ACLs, and "new" CA ACLs that don't have
> any CAs defined.  However, adding a new objectclass resolves this
> ambiguity.

I'm not sure if this can be handled properly during upgrade only.

One could have a 4.3 server and 4.4 replica, add a CA ACL on the 4.3 
server and then uninstall the server, which would leave the CA ACL not 
upgraded for indeterminate time.

Also we should keep "old" CA ACLs working on 4.3 servers, otherwise we 
would break cert-request on them, and I don't think this can be done 
without changing the object class at runtime.

>
> Lmk what you think; I could be way off track :)
>
> Cheers,
> Fraser
>


-- 
Jan Cholasta