On Wed, 2018-03-07 at 16:23 +0100, Jakub Hrozek wrote: > > 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. > 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 -- firstname.lastname@example.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org