© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
> @Dan: have you actually confirmed, that building and running userdbd solves those issues with NIS and LDAP?
sorry for the delay in getting back to this.
So, you're correct, userdb doesn't actually help this, it only moves the problem.
While systemd-
So if we include systemd-userdbd in Debian/Ubuntu, then the network-restricted systemd-logind problem is simply moved to systemd-userdbd. I will note that I did verify, if systemd-logind is running with its default restrictions and systemd-userdbd is also running without its IPAddressDeny=any restriction, the issue is fixed; systemd-logind does correctly get the user record from NIS through systemd-userdbd.
I also seem to have misunderstood Lennart's position on this; after re-reading his statements[1] it seems that his position is that *all* systemd services should be locked down (or at least, both systemd-logind and systemd-userdbd) and the responsibility for poking holes in one (or both, or more) of those services' restrictions is on NIS and any other NSS library that requires network access.
So enabling systemd-userdbd won't help with this bug, unless we want to diverge from upstream by removing its IPAddressDeny=any restriction. But we could just as easily remove that from systemd-logind (along with adding AF_INET and AF_INET6 to it).
[1]:
https:/
https:/