On Wed, Mar 7, 2018 at 5:56 AM Tom Hughes <tom@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
