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 https://github.com/systemd/systemd/issues/7074#issuecomment-338157851 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