On Mon, 2018-09-24 at 11:38 +0200, Jakub Hrozek wrote: > > On 21 Sep 2018, at 20:36, [email protected] wrote: > > > > For our case, say we have a set of groups abcd..1, abcd..2 etc, all > > with the same GID. I would expect the first lookup (e.g. abcd..1) > > to put an entry in the cache. If there is then a lookup by GID, > > (getent group <GID>) it would return this entry. However a lookup > > by name (e.g. abcd..2) would have to query LDAP, right? Then what > > happens, does this new data overwrite the old GID entry in the > > cache? Or is there some bug whereby sometimes a duplicate entry > > gets made? Why is there a check for duplicates when a GID is looked > > up as opposed to when an entry is placed in the cache? > > I’m not so sure it would be a good idea to support this, honestly. > What do you suggest would then be returned for lookups by GID > (getgrgid 1234) if there are multiple entries with GID=1234 in the > cache? Just let the first match win? I know this is what nss_ldap > does, whatever is returned from LDAP is then passed on to NSS, but > I’m mostly concerned about consistency, suppose a first machine does > getent group abcd..1, another one does geten group abcd..2. Then you > get a different result on each machine for by-GID request..
For groups I would expect us to merge memberships in rfc2307 mode, and keeping the alphabetically "smaller" name as the group name for predictability. For RFC 2307bis it may be a little harder because of nested membership stuff, that needs a little bit more thinking. Maybe allow it only for RFC2307 trees ? > LDAP also doesn’t guarantee any ordering of results AFAIK (even > though in practice I’ve seen the replies are quite consistent), so > it’s even not guaranteed to always receive the same answer for the > by-GID LDAP search.. > > btw it’s a good question to ask why isn’t the check done on saving > the group. I thought it was and I see code that checks for ID > uniqueness and even a test.. In current code, saving would override data as if the group was renamed changed I think ? 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]
