> On 7 Mar 2018, at 15:53, Stephen Gallagher <sgall...@redhat.com> wrote: > > > > On Wed, Mar 7, 2018 at 9:50 AM Simo Sorce <s...@redhat.com> wrote: > 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. > > > Probably the simplest solution for sysusers would be to execute the change > and then run a wait-loop calling `getpwnam(<newly-added-user>)` until it gets > a successful result (or some reasonable timeout expires, indicating a bug > elsewhere). That way, it can be trusted that sysusers won't return until the > user addition is truly valid.
btw if nss_sss wouldn’t find the user, then, assuming the default order on Fedora, the request would just fall back to nss_files. So I don’t think the race condition when /adding/ a user is something to worry about. But the other way around, if the user was removed, there can be a small race between removing the user and nss_sss having its cache flushed. I don’t think this is any different from nscd either. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
