It's a good discussion, and I don't necessarily disagree with your thoughts on groups with the same GID, despite the nss_ldap implementation. I'd agree that any change in behavior should have an option to revert to previous but that it shouldn't be the default.
However, is the issue with duplicate entries in the cache an artifact of this problem, or is it unrelated? If the latter then it should be a separate bug report/fix that could then be worked on ahead of any kind of agreement on duplicate GIDs. I suspect that whatever the decision, it's not going to happen in any kind of short time frame. What I will probably have to do is revert to a non-SSSD configuration in SLES 12 to get things working as before until we can get the split groups aligned into single entries. Gareth -----Original Message----- From: Simo Sorce [mailto:[email protected]] Sent: Monday, September 24, 2018 8:46 AM To: End-user discussions about the System Security Services Daemon <[email protected]> Subject: [SSSD-users] Re: Issues with SSSD cache on version 1.13.4 On Mon, 2018-09-24 at 16:44 +0200, Michael Ströder wrote: > On 9/24/18 4:22 PM, Simo Sorce wrote: > > For groups I would expect us to merge memberships in rfc2307 mode, > > If you really want to implement such merging then please disable it by > default. So that it must be explicitly enabled after careful > consideration. Yes it would have to be optional and disabled by default, we do not want to promote bad practices. What we can do to make the code more predictable (albeit slower) is to always "reverse resolve" by gid (and by name) whenever a search by name (or by gid) is performed, so duplicates are always consistently dealt with (either first in alphabetic order only or always completely fail to accept a group with duplicate gid (or name). This check can be optimized on servers that support dereference controls. Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
