#3684 A group is not updated if its member is removed with the cleanup task, but the group does not change
Closed: Fixed a year ago Opened a year ago by tjb900.


I'm seeing pretty much exactly the symptoms described in #2676, but in Centos 7.4:

[root@lnod0028 ~]# rpm -qa | grep sssd

I think the sequence of events goes like this:

  • load group into cache (getent group teamX), all users are ghosts
  • load userX (a member of teamX) into cache (getent passwd userX), so it becomes not-a-ghost member of group
  • (wait)
  • load another member of teamX (getent passwd userY) into cache, so it too becomes not-a-ghost member of group.
  • wait until userX gets expired, but not userY otherwise the group itself will be purged too
  • group now does not contain ghost for userX, BUT (thanks to fixes in #2676) the group marked as expired
  • now perform getent group teamX
  • userX is nonetheless missing from the group

I think this line in the log is the key, which occurs at the time of the final getent group:

(Tue Mar 20 03:54:18 2018) [sssd[be[LDAP]]] [sysdb_store_group] (0x1000): The group record of teamX@ldap did not change, only updated the timestamp cache

I think there is an optimisation added since the #2676 fixes, which causes the invalid cache entry not to be refreshed, because it has not changed server-side. This is because the fixes for #2676, instead of re-adding the ghost, rely on a cache refresh to accomplish that - and the cache refresh is now effectively optimised away.

Details below, please let me know if you need more!


The shell script to reproduce, with specific user/group names replaced:

rm -f /var/lib/sss/db/*; rm -f /var/log/sssd/*; service sssd restart

# Get group into cache
getent group teamX

# Get user into cache
getent passwd userX

# Later, get another user into cache
sleep 120; getent passwd userY

ldbsearch -H /var/lib/sss/db/timestamps_LDAP.ldb dn=name=teamX@ldap,cn=groups,cn=LDAP,cn=sysdb

# Wait for first user entry to expire but not the second
sleep 85

ldbsearch -H /var/lib/sss/db/timestamps_LDAP.ldb dn=name=teamX@ldap,cn=groups,cn=LDAP,cn=sysdb

# Show group, will not have userX in it now
getent group teamX

ldbsearch -H /var/lib/sss/db/timestamps_LDAP.ldb dn=name=teamX@ldap,cn=groups,cn=LDAP,cn=sysdb

Dump of sssd conf (have artificially reduced timeouts to show issue):

config_file_version = 2
services = nss, pam, sudo, autofs
debug_level = 7

domains = LDAP

nss_filter_groups = root
nss_filter_users = root
debug_level = 7

debug_level = 7

id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
sudo_provider = ldap
autofs_provider = ldap
domain_type = posix
ldap_uri = ldap://myserver
ldap_search_base = dc=myorg,dc=com
cache_credentials = True
enumerate = False

entry_cache_timeout = 180
entry_cache_group_timeout = 5000

ldap_id_use_start_tls = True
ldap_tls_cacert = /etc/pki/tls/certs/ca.crt
tls_reqcert = allow
ldap_default_bind_dn = XXX

ldap_user_search_base = ou=people,dc=myorg,dc=com???ou=systemusers,dc=myorg,dc=com??
ldap_group_search_base = ou=group,dc=myorg,dc=com
ldap_sudo_search_base = ou=SUDOers,dc=myorg,dc=com

ldap_autofs_search_base= ou=london_automount,ou=admin,dc=myorg,dc=com





Thank you for the bug report, I have a local patch available. I'll submit it to PR once I write a test as well.

And thank you for the detailed reproducer and the analysis of the situation, both were spot-on.

Metadata Update from @jhrozek:
- Issue assigned to jhrozek

a year ago

Metadata Update from @jhrozek:
- Issue tagged with: PR, bug

a year ago

Metadata Update from @jhrozek:
- Issue set to the milestone: SSSD 1.16.2

a year ago

Metadata Update from @jhrozek:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

a year ago

Login to comment on this ticket.