systemd-resolved and nss_ldap

[lennart@xxxxxxxxxxxxxx (Lennart Poettering)]

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

-- 
Lennart Poettering, Red Hat