On Mon, 2018-09-24 at 11:38 +0200, Jakub Hrozek wrote:
> On 21 Sep 2018, at 20:36, gfbhwo(a)yahoo.com 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
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 ?
Sr. Principal Software Engineer
Red Hat, Inc