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

Hi!

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

[root@lnod0028 ~]# rpm -qa | grep sssd
sssd-1.15.2-50.el7_4.6.x86_64

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!

Cheers,
Tim


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):

[sssd]
config_file_version = 2
services = nss, pam, sudo, autofs
debug_level = 7

domains = LDAP

[nss]
nss_filter_groups = root
nss_filter_users = root
debug_level = 7

[domain/LDAP]
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_default_authtok_type=XXX
ldap_default_authtok=XXXX


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
ldap_autofs_search_map_object_class=automountMap
ldap_autofs_map_object_class=automountMap
ldap_autofs_map_name=ou
ldap_autofs_entry_object_class=automount
ldap_autofs_entry_key=cn
ldap_autofs_entry_value=automountInformation


ldap_enumeration_refresh_timeout=300
ldap_purge_cache_timeout=60
ldap_search_timeout=2
ldap_enumeration_search_timeout=10
ldap_network_timeout=2


[pam]

[sudo]

[autofs]

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

7 years ago

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

7 years ago

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

7 years ago

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

7 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/4703

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Log in to comment on this ticket.

Metadata