Simo Sorce wrote:
On Wed, 2013-02-27 at 15:00 -0500, Rob Crittenden wrote:
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

the local ranges ^^ the admin may have already added additional ones, so
it needs to be plural.

we're going to go through the trouble of keeping them in sync we should
be consistent.

Otherwise good plan.

It is worded better in the wiki to not imply this covers only a single local range.

rob

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to