Am 12.06.19 um 14:06 schrieb Petter Reinholdtsen:
> If I understand the problem correct, systemd changed the setup to block access
> to the network for several services used during login, and this break
> any NSS module fetching information from a network service, like the NIS
> one.

More specifically, systemd-logind.service was locked down considerably
including IPAddressDeny=any

   If so, this problem will affect others, like libnss-ldap and
> libnss-mdns, and is not NIS specific.  It will not affect NSS modules
> with a separate daemon connecting to the network service, like libnss-ldapd
> and libnss-sss.
> The recommondation to use the Name Service Cache Daemon (nscd) will cause
> new and interesting problems with NIS, and is perhaps not the best way to
> solve this.  The NSCD cache some times will end up in an inconsistent state,
> and might cause users to log in with an incomplete set of groups, if I
> recall the problem correctly.
> It seem safer to not block all network connections when some of the
> "network enabled" NSS modules are active.

See Lennart's comment at

He suggests that the nis package could ship a drop-in config snippet in
/lib/systemd/system/systemd-logind.service.d/ which turns off that
sandbox feature.
This seems like a reasonable fix that would be worthwile having in
buster in case anyone still cares for the nis package.

Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to