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.
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
