On Wed, 2018-03-07 at 14:24 +0000, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Mar 07, 2018 at 02:00:03PM +0100, Florian Weimer wrote: > > On 03/07/2018 01:55 PM, Stephen Gallagher wrote: > > > Yes, SSSD monitors those files and automatically cleans its cache. > > > > > > However, you're right. On systems not using SSSD (which I suspect is a > > > nontrivial number of systems running systemd...), people are probably still > > > using nss and we should call `nscd -i passwd` (plus `group` and `shadow` > > > where appropriate) if the nscd service is running. > > > > nscd is supposed to monitor these files, too. > > > > But is this monitoring sufficient? RPM will immediately start > > installing files after the scriptlet has finished. nscd and SSSD > > may not have completed their cache invalidation at this point, so > > this looks like a race condition to me. > > That sounds like a bug in the cache implementation. nscd and sssd > simply _must_ ensure that their copy of passwd is the latest one. > Shouldn't be a problem to call fstatat() before generating an answer > an invalidate the cache if it returns a different mtime then previously. The fast cache we provide from sssd is read directly by the client (sssd nsswitch plugin) without the involvement of the sssd daemon (or it would be slow). so there are windows for races if you change a passwd file and then immediately read out of the fast caches. This is not something we can fix without severely compromising performance, which is the raison d'etre of those caches. Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
