On Tue, Dec 15, 2020 at 02:53:28PM +0100, Thomas HUMMEL wrote:
> 
> Hello,
> 
> I'm using sssd-2.2.3 on CentOS 8.2.2004 with an ldap (actually the ldap
> exposed by an Active Directory server) backend.
> 
> This works fine but I'm having a hard time trying to figure out how
> different caches actually work. I've read about the different *cache*
> directives in sssd.conf(5).
> 
> I'm trying to understand what exactly happens when I:
> 
>     - add a group membership for a user in the ldap directory
> 
>     - then test different combinations of 'id' or 'id <user>' commands and
> opening or not of a new shell (via ssh) regarding the delay for the new
> membership to appear (or not ?) on the client
> 
> # My setup :
> 
> - 2 domains are defined but only one is used :
> 
>     domains = foo_home
> 
> - auth provider is ldap with the AD schema :
> 
>     auth_provider = ldap
>     ldap_schema = AD
> 
> - initially, no *cache* directive is present
> 
> - on Centos 8.2 nsswitch is configured with sss first :
> 
>     passwd:     sss files systemd
>     group:      sss files systemd
> 
> # My understanding is that (but I might be wrong):
> 
> 1) there's caching of user/group resolutions somewhere else (glibc ? shell
> ?) from sssd
> 
> 2) running 'id' is different from running 'id <user>' (as with the latter
> there is name resolution involved ?)
> 
> 3) sssd.conf directives I might be interested in tweaking in my case are the
> domain-scope ones below:
> 
>     entry_cache_timeout
>     entry_cache_user_timeout
>     entry_cache_group_timeout
> 
> but mostly entry_cache_user_timeout
> 
> So I added, as a test,
> 
>     entry_cache_user_timeout = 5
> 
> # What I experience
> 
> I'm starting with a new sssd instance without cache :
> 
> # sss_cache -E
> # systemctl stop sssd
> # sss_cache -E
> # rm /var/lib/sss/db/*
> # systemctl start sssd
> 
> 
> Note: I'm not sure if sss_cache acts upon offline sssd
> 
> 1) shell A, logged in as user foo : id | grep -i 'new_group' or id foo |
> grep -i 'new_group' does not match anything
> 
> 
> 2) add 'foo' into 'new_group' on the ldap backend
> 
> 3)
> 
>     a) test 1
> 
>     after 5 minutes:
> 
>         - shell A : id foo | grep -i 'new_group' shows the new group
> membership
>          - but shell A : id | grep -i 'new-group' still does not match
> anything
> 
>     b) test 2
> 
>     user foo logs into shell B:
> 
>         - in shell B : id | grep -i 'new_group' and id foo | grep -i
> 'new_group' *both* show the new membership
>         - in shell A : id | grep -i 'new_group' still does not show the new
> membership, but id foo | grep -i 'new_group' does
> 
> Can you help me explain what exactly is going on and what cache(s) is(are)
> involved in each case ?

Hi,

the reason for the difference is that 'id' without a username returns
the secondary group memberships of the current session of the user. At
login time the current group memberships are checked and assigned to the
process started, which is the shell in your case. The secondary group
list is a property of the process and does not change automatically. The
secondary groups are also inherited to child processes when they are
created. You can verify this by checking the 'Groups' entry of
/proc/PID/status.

So 'id' called in shell A will always return the same results. Even if
you remove the user and all groups on the server side 'id' will still
show the groups in the still running shell, but it will only show the
numerical values since the names cannot be resolved anymore.


If 'id' is called with a user name the glibc nss interface is used to
determine the group memberships provided by the nss modules configured
in /etc/nsswitch.conf. This basically means that SSSD, /etc/passwd and
/etc/groups and other sources are checked for group memberships.

HTH

bye,
Sumit

> 
> Thanks for your help
> 
> -- 
> Thomas HUMMEL
> 
> 
> aa
> _______________________________________________
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org

Reply via email to