URL: https://github.com/SSSD/sssd/pull/128 Title: #128: Fix group renaming issue when "id_provider = ldap" is set
jhrozek commented: """ On Tue, Feb 14, 2017 at 05:41:34AM -0800, fidencio wrote: > On Tue, Feb 14, 2017 at 2:07 PM, lslebodn <notificati...@github.com> wrote: > > > On (14/02/17 01:57), fidencio wrote: > > >@lslebodn: > > >Firstly, my answer may be incomplete due to the lack of knowledge, but > > let's try ... > > >1) As far as I understand SSSD does not deal properly with multiple > > groups having the same GID and I'm saying that based on both AD's and > > LDAP's code, where the search is done by the GID and we expect only one > > result; > > > > Yes, we expect but reality is different and we got > > bug reports about incomplete groups. > > And result of bug investigation was colliding GIDs. > > > > Current version detects that there is a collision of GIDs > > and will not return any result for problematic groups. > > > > >2) We already have at least one bug opened for this situation ( > > https://fedorahosted.org/sssd/ticket/2982) and in case we decide to deal > > properly with this my feeling is that it will have to be done in all > > different parts of the code. > > > > > >I understand why you're worried and I see we can hit this situation. But > > we can hit this situation even without my fix. So I'd like to propose to > > fix this situation when someone has time to work on this and in a better > > way than just "don't deal with group renaming". > > > > > > > Yes we can hit this situation without your fix but I am curious > > what will be a difference between current behaviour and with this PR. > > > With this patch we will end up removing one of first group cached with the > gid and update with the new one. > Yes, as you mentioned, it's a corner case. And yes, as you said, it may > bite us really hard in the future. > > So, I'd like to ask for suggestions (@sbose ?, @jhrozek ?) on how to deal > with this. I wonder if a low-tech solution would help here. In case we hit this codepath, issue a really loud debug message informing that a group was renamed from X to Y and if the group was renamed on the server, it's expected, otherwise it's an error. btw we should (unless we already do) check that requests by ID return only one result. > > In case we get bitten by one of those two bugs, which one would hurt less? > > Also, would be nice to see some bug reports about this (in case you have > those handy, @lslebodn). I don't remember those off-hand, but I know there were some and that's the reason we added debug messages to the NSS responder informing about ID duplicates. > > Last but not least, @lslebodn suggested (in face to face conversation in > the office) that maybe we could add an option which would be used for > fixing the group renaming for whoever reported this bug (and this option > wouldn't be enabled by default). Opinions on Lukáš' idea? I'm not sure..it does steer towards the safe side, but on the other hand, renaming a group is a legally fine operation and I'm not sure I like an option that the admin must enable in order to proceed with an OK operation.. """ See the full comment at https://github.com/SSSD/sssd/pull/128#issuecomment-279754463
_______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
