systemd-resolved and nss_ldap

[vovan@xxxxxxxx (Vlad)]

Lennart,

Thanks for all the information amd explanation! Below is all the details:
- systemd-239
- systemd-resolve as well ass all systemd related users are defined in
/etc/passwd
- nss_ldap is configured via nss_initgroups_ignoreusers to not lookup
groups fro all system related users include all systemd users

Do you think changing "DynamicUser" to "no" should solve the issue? I
see that quite a few services (systemd-resolve, systemd-networkd,
firewalld, etc.)Â  have "DynamicUser=yes".

Regards,
Vlad.


On 04/07/18 13:03, Lennart Poettering wrote:
> On Di, 03.07.18 22:16, Vlad (vovan at vovan.nl) wrote:
>
>> Hello,
>>
>> It looks like the combination of systemd-resolved service for DNS name
>> resolution with nss_ldap hangs the system during boot. Particularly the
>> following configuration in nsswitch.conf leads to boot problem:
> Which systemd version is this?
>
> Since 239 systemd-resolved will use DynamicUser=1 to allocate its user
> ID dynamically. Previously that user was statically defined in
> /etc/passwd. Allocating a user dynamically means it needs to be tested
> against /etc/passwd, where it won't exist generally. I figure you are
> getting a dead lock due to that, as nss-ldap will probably get into
> effect if a user is looked for that doesn't exist in
> /etc/passwd. nss-ldap then probably freezes on trying to connect to
> some network server through DNS which in turn causes resolved to be
> triggered but it can't, after all that's what we are currently in the
> process of doing...
>
> I am pretty sure it's not the best design today that nss-ldap inserts
> a complex, network facing piece of code into all kinds of system
> processes the way it does, even the most benign ones such as
> "ls". This is security sensitive stuff after all...
>
> One simple work-around is to pre-allocate the "systemd-resolve" user
> statically in /etc/passwd (i.e. create it with normal
> useradd/adduser). That way nss-ldap won't get triggered.
>
> I'll add a brief note about this to the NEWS file, since this might be
> something other folks using network-facing NSS modules might run into.
>
> It might be worth finding a way to turn off nss-resolve automatically
> when we are preparing start-up for systemd-resolved. I'll look into
> that.
>
> Lennart
>