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.