On Fri, 2014-07-11 at 17:20 +0200, Jakub Hrozek wrote:
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
Systemd would be wrong.
My plan is indeed to use login.defs if available and fallback to a
hardcoded compile-time default if not.
Simo.
--
Simo Sorce * Red Hat, Inc * New York