[Freeipa-devel] [PATCH] 798 Fix indirect member calculation

[Martin Kosek]

On Mon, 2011-06-13 at 23:37 -0400, Simo Sorce wrote:
> On Mon, 2011-06-13 at 23:28 -0400, Rob Crittenden wrote:
> > Endi Sukma Dewata wrote:
> > > On 6/13/2011 6:00 PM, Rob Crittenden wrote:
> > >> Endi Sukma Dewata wrote:
> > >>> On 6/13/2011 2:45 PM, Rob Crittenden wrote:
> > >>>> Indirect membership is calculated by looking at each member and pulling
> > >>>> all the memberof out of it. What was missing was doing nested searches
> > >>>> on any members in that member group.
> > >>>>
> > >>>> So if group2 was a member of group1 and group3 was a member of
> > >>>> group2 we
> > >>>> would miss group3 as being an indirect member of group1.
> > >>>>
> > >>>> I updated the nesting test to do deeper nested testing. I confirmed
> > >>>> that
> > >>>> this test failed with the old code and works with the new.
> > >>>>
> > >>>> ticket https://fedorahosted.org/freeipa/ticket/1273
> > >>>
> > >>> NACK. If a user is an indirect member of a group via 2 different paths,
> > >>> the user will be listed twice. Here is a test scenario:
> > >>>
> > >>> Group 1 has 2 members: group 2 and group 3.
> > >>> User X is a member of both group 2 and group 3.
> > >>> Group 1's indirect members should only list the user X once. Currently
> > >>> it is listed twice.
> > >>
> > >> Patch and test case updated.
> > >
> > > NACK. If there's a circular membership the code will run into an
> > > infinite loop. Here's a test scenario:
> > >
> > > Group 1 has 2 members: group 2 and group 3.
> > > Group 2 is a member of group 3.
> > > Group 3 is a member of group 2.
> > > Run ipa group-show on group 1, the command doesn't return until it's
> > > killed.
> > >
> > 
> > I think the solution will be to deny creating circular groups.
> 
> Although it would be nice to avoid creating circular groups as they are
> pointless we really can't assume we can prevent that. In a multi-master
> scenario it is possible that 2 admins operating on 2 different masters
> will end up creating a circular group dependency. Even though on each
> master they will not be, until replication takes place.
> 
> So we MUST (capital as in RFCs) deal with circular groups in the UI and
> framework. Entering infinite loops is not an option, use a max-recursion
> limit if detecting circular deps is too hard.
> If you set the max-recursion limit high enough you will still operate
> properly in most scenarios with complex memberships w/o side effects.
> 
> Simo.
> 

IIRC the algorithms for circular groups processing are already
implemented in SSSD, so we don't have to reinvent the wheel and let us
get some inspiration there :-)

Martin