I’m not so sure it would be a good idea to support this, honestly.
Well that rather depends on what you mean by "this". I was reporting a problem
that seemed an inconsistency to me. Either multiple groups with the same GID are
supported, or they aren't. The current implementation is inconsistent in its response
over time, and it flags an error and then fails - that should not happen in either
scenario.
I think one has to be careful in applying rules that haven't been applied in the past.
Since using GIDs in this way is a "hack" but has been used in the past, albeit
with the expectation that some corners don't work properly, changing the behaviour
needs to be carefully thought out. The example case you state does produce differing
results with nss_ldap, so should that really change? I suspect it is the way it is because
there's no clear "right" way to handle it. For the most part, an /etc/group
file or LDAP directory doesn't prevent duplicate GIDs, so should that restriction
really be applied by the caching service?
In practical terms, since the first lookup results depend on LDAP, SSSD doesn't even
know there are multiple groups with the same GID, so I don't think it even can reject
looking up such a group. Arguably, a lookup by GID should return ALL entries with that GID
and put them as a single entry in the cache, even if they have different names. This of
course is behavior different from nss_ldap, and who knows if you can even ask LDAP for
it?
It looks like you have established some kind of checking is done, but nonetheless SSSD is
reporting a duplicate entry. So either there's a path through the code that bypasses
the checks, or the error report itself is in error. I have not been able to establish
which. The ldbsearch utility reports zero entries for the GID, and indeed zero entries if
I try to list "all". IS there another way to query the SSS DB? I think tdbtools
can do it, but the utility doesn't have the fine-grained queries that ldbsearch seems
to.
Gareth
-----Original Message-----
From: Jakub Hrozek [mailto:jhrozek@redhat.com]
Sent: Monday, September 24, 2018 2:38 AM
To: End-user discussions about the System Security Services Daemon
<sssd-users(a)lists.fedorahosted.org>
Subject: [SSSD-users] Re: Issues with SSSD cache on version 1.13.4
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..
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..
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
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/sssd-users@lists.fedorahoste...