[SSSD] On taking over serving Local user accounts

Jakub Hrozek jhrozek at redhat.com
Fri Jul 11 15:20:54 UTC 2014


On Fri, Jul 11, 2014 at 06:20:13AM -0400, Simo Sorce wrote:
> One of the plans for better desktop integration is to slowly take over
> local accounts by creating a new provider that uses system files
> (passwd, shadow, group, etc...) and augments them with additional
> information maintained in sssd's long term cache.
> 
> Part of this plan calls for changing how nsswitch is configured so that
> the sss nsswitch module comes first. This is useful for a variety of
> reasons, including that we can cache in the fast cache user's from
> passwd/group too and do not pay the penalty of going through the slower
> nss_files provider for each request.
> 
> However this comes with a gotcha when sssd is stopped, as the cache will
> not be updated. This is particularly important at bootup time when sssd
> is not started yet but some daemons already exist and start consulting
> user entries. In order to avoid issues I think we should make it
> possible for nss_sss to understand whether it can actually trust caches
> or not.
> 
> One idea is to mark "system" users/groups in the cache,

How do you distinguish the system users? Based on ID limits or some other
property (such as, no shadow entry)? Reading the fedora-devel thread again, I
think the systemd proposal includes going away from the MIN_ID/MAX_ID limits
in /etc/login.defs, so I guess we'll have to implement a compile-time option

> and have nss_sss
> ignore them if they are in the cache but it is not possible to connect
> to sssd. This should be pretty lightweight as it just tries to connect
> to the sssd socket but does not need to make any communication on it
> except for the first request and getting a "echo" or "version" packet
> (just to check sssd_nss is actually alive).
> 
> If connection to sssd_nss fails then nss_sss will not return the system
> user and the query will naturally fall back to use nss_files instead.
> 
> We may want to use some very strict timeout on the socket for this
> specific case, to avoid stalling the boot process, it's not a bid deal,
> the process falls back to using nss_files so we are always correct in
> any case.
> 
> Simo.
> 
> -- 
> Simo Sorce * Red Hat, Inc * New York
> 
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel



More information about the sssd-devel mailing list