Bug 785888 - sssd returns empty netgroup at a second request for an non-existing netgroup
Summary: sssd returns empty netgroup at a second request for an non-existing netgroup
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd
Version: 6.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Stephen Gallagher
QA Contact: IDM QE LIST
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-01-30 20:27 UTC by Stephen Gallagher
Modified: 2020-05-02 16:19 UTC (History)
5 users (show)

Fixed In Version: sssd-1.8.0-2.el6.beta2
Doc Type: Bug Fix
Doc Text:
Cause: nss responder uses negative cache to eliminate the need for asking provider for non-existent entity multiple times. However in case of netgroups the querying process didn't work well with the negative cache. Consequence: in some cases an empty netgroup could have been returned to client even if it actually didn't exist Fix: nss responder has been changed to use special flag indicating that the group has been found in the cache instead if using negative cache for netgroup lookups Result: netgroup queries no longer return empty netgroups if they don't exist in the cache
Clone Of:
Environment:
Last Closed: 2012-06-20 11:54:30 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 1862 0 None closed sssd returns empty netgroup at a second request for an non-existing netgroup 2020-05-02 16:19:13 UTC
Red Hat Product Errata RHBA-2012:0747 0 normal SHIPPED_LIVE sssd bug fix and enhancement update 2012-06-19 19:31:43 UTC

Description Stephen Gallagher 2012-01-30 20:27:26 UTC
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/sssd/ticket/820

The following behaviour can be seen when requesting a non-existing netgroup:

{{{
$ getent netgroup unknown_netgroup
$ getent netgroup unknown_netgroup
unknown_netgroup
}}}

getent netgroup should always return nothing if the netgroup does not exists.

Comment 4 Jan Zeleny 2012-04-04 10:47:25 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause: nss responder uses negative cache to eliminate the need for asking provider for non-existent entity multiple times. However in case of netgroups the querying process didn't work well with the negative cache.
Consequence: in some cases an empty netgroup could have been returned to client even if it actually didn't exist
Fix: nss responder has been changed to use special flag indicating that the group has been found in the cache instead if using negative cache for netgroup lookups
Result: netgroup queries no longer return empty netgroups if they don't exist in the cache

Comment 5 Amith 2012-04-11 10:03:36 UTC
Verified on sssd-1.8.0-22.el6.x86_64. 

The output for the associated beaker automation script is given below:

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: [   LOG    ] :: Verify BZ release ticket #336 :- sssd returns empty netgroup at a second request for an non-existing netgroup
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

:: [   PASS   ] :: Verify BZ release ticket #336
:: [   PASS   ] :: Verify BZ release ticket #336
:: [   PASS   ] :: Verify BZ release ticket #336
:: [   LOG    ] :: Duration: 14s
:: [   LOG    ] :: Assertions: 6 good, 0 bad
:: [   PASS   ] :: RESULT: Verify BZ release ticket #336 :- sssd returns empty netgroup at a second request for an non-existing netgroup

Comment 7 errata-xmlrpc 2012-06-20 11:54:30 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0747.html


Note You need to log in before you can comment on or make changes to this bug.