On Wed, Mar 7, 2018 at 5:56 AM Tom Hughes <t...@compton.nu> wrote:
> On 07/03/18 10:46, Zbigniew Jędrzejewski-Szmek wrote:
> > On Wed, Mar 07, 2018 at 10:28:58AM +0000, Tom Hughes wrote:
> >> On 07/03/18 10:10, Florian Weimer wrote:
> >>> On 03/06/2018 03:24 PM, Zbigniew Jędrzejewski-Szmek wrote:
> >>>> It's a very simple tool to create system users and group in
> /etc/passwd.
> >>>> It just creates entries in/etc/{passwd,group,shadow}, and does not
> >>>> interact with audit in any way afaik.
> >>>
> >>> Does it perform any locking or cache invalidation?
> >>
> >> It appears to do locking:
> >>
> >>
> https://github.com/systemd/systemd/blob/master/src/sysusers/sysusers.c#L1953
> >>
> >> which is calling:
> >>
> >>
> https://github.com/systemd/systemd/blob/master/src/basic/user-util.c#L548
> >>
> >> which takes a write lock on /etc/.pwd.lock around everything.
> > Ack.
> >
> > Cache invalidation? I'm not sure what you mean, it just replaces the
> > file atomically and syncs the file system.
>
> Well historically nscd I guess though I think sssd is supposed to
> have replaced that now?
>
> I believe sssd watches the files with inotify and does it's own
> cache invalidation - a quick test with strace suggests it notices
> when I edit the groups file with vi.
>
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.
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
