[Freeipa-devel] DESIGN: Recover DNA Ranges

Rob Crittenden rcritten at redhat.com
Wed Feb 27 20:00:10 UTC 2013


Sumit Bose wrote:
> On Wed, Feb 27, 2013 at 02:03:24PM -0500, Rob Crittenden wrote:
>> Sumit Bose wrote:
>>> But it looks like dnarange-set and dnanextrange-set can also be used to
>>> not only move existing DNA ranges but to create new DNA ranges which
>>> will lead to ID which are not in the idrange of the IPA domain but might
>>> be in an idrange which is used by a trusted domain. So I think a check
>>> and a warning are desirable.
>>
>> That is an excellent point. I've updated the design.
>
> Thank you. I would like to suggest a slight edit. Instead of
>
> "That doesn't remove our responsibility to not test for overlaps in the
> idranges though. We will need to verify that the manual configuration
> changes do not overlap with all ranges in cn=ranges,cn=etc,$SUFFIX."
>
> I would say
>
> "That doesn't remove our responsibility to not test for overlaps in the
> idranges though. We will need to verify that the manual configuration
> changes do
> * not overlap with ranges from trusted domains
>    (objectclass=ipatrustedaddomainrange) in cn=ranges,cn=etc,$SUFFIX, or
>    reject the change otherwise.
> * overlap completely with ranges from the local IPA domain
>    (objectclass=ipaDomainIDRange) in cn=ranges,cn=etc,$SUFFIX, or give a
>    warning otherwise which asks the user to add a new suitable idrange."
>
> Codewise the logic could be:
> - check if the new range is a subset of a local idrange, if yes, all is
>    fine
> - if not, check if it overlaps with an idrange of a trusted domain, if
>    yes, reject
> - if not, give a warning and ask to add a new idrange for the local
>    domain

I took this almost verbatim but I'm more harsh. If the range is outside 
the local range and not overlapping anything I will still reject it. If 
we're going to go through the trouble of keeping them in sync we should 
be consistent.

thanks

rob




More information about the Freeipa-devel mailing list