On Wed, 2018-03-07 at 16:23 +0100, Jakub Hrozek wrote: > > On 7 Mar 2018, at 15:53, Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > > > > > > > > On Wed, Mar 7, 2018 at 9:50 AM Simo Sorce <simo@xxxxxxxxxx> 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. > changing or removing users are the cases where races matters, just adding is not indeed. Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
