#1846 cyclic group memberships may not work depending on order of operations
Closed: Fixed None Opened 6 years ago by jhrozek.

Lukas found that depending on the order we save groups to cache, we might fail to save cyclic group memberships correctly. With a setup like this:

   ________
   |  CG1 |------------>sssduser1
   |______|<---+
      |        |
      |        |
      |     ________
      +---->|  CG2 |--->sssduser2
            |______|

Then depending on whether CG1 or CG2 is requested first, then only sssduser1 or only sssduser2 may be returned.

The logs would show an EEXIST situation from memberof plugin.


Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.10.0

Fields changed

milestone: SSSD 1.10.0 => SSSD 1.10.1

Fields changed

changelog: =>
owner: somebody => okos
status: new => assigned

Ondra, this is a bug in the memberof plugin. I don't think it's trivial (the memberof plugin is quite complex and delicate code base) so feel free to pick another ticket instead if you feel that this would be too much for start.

I was going to close this issue as notabug. I tried to reproduce this yesterday with IPA and LDAP id providers, but everytime the groups were returned correctly. I asked Lukas to give me precise steps, since he found this issue, but now he couldn't reproduce this as well. We'll try to find when and where this could've been fixed, but there were no modifications in memberof plugin since the bug was reported.

Aaah, I confused this ticket with #1654, sorry. Carry on :)

Fields changed

owner: okos => lslebodn
status: assigned => new

Fields changed

patch: 0 => 1
status: new => assigned

owner: lslebodn => jhrozek
status: assigned => new

Fields changed

owner: jhrozek => lslebodn

Fields changed

resolution: => fixed
status: new => closed

Fields changed

changelog: => N/A, just a bugfix

Metadata Update from @jhrozek:
- Issue assigned to lslebodn
- Issue set to the milestone: SSSD 1.10.1

2 years ago

Login to comment on this ticket.

Metadata