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

Reply via email to