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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel