One good point in favor of including systemd-userdbd in Debian/Ubuntu would be that we only need to adjust the restrictions for that service; all other systemd-provided services would use (or at least, *should* use...) systemd-userdbd to get user records. I'm not sure if that is actually worth including and using systemd-userdbd to the distro.


Putting that aside for now, I think the only options to fix this all involve removing the systemd-logind restriction(s). The only question seems to be what/who removes the restrictions.

1) We could simply remove the restrictions for systemd-logind in the Debian/Ubuntu package, for everyone. This would (theoretically) reduce the security of systemd-logind by allowing it to access the network, but also it would allow network-based NSS lookups to work in all situations (meaning, for all possible NSS modules, not only NIS and/or select other packages/modules).

2) We could add drop-in files to remove the restrictions for systemd-logind, for the 'nis' package (which I think has been split out in later releases and in Debian, so we'd need to pick the correct client package). We would also need to include drop-in files for any other package that provides an NSS module that needs to perform network lookups, such as the 'libnss-ldap' package (I haven't verified this needs network access but I believe it does, e.g. comment 7 above).

3) We could simply add documentation to the README and/or man pages and/or other docs and leave it up to the system admin to add the systemd-logind drop-in file when they set up NIS or LDAP or whatever other network-based auth provider.


Personally, I think #3 is barely better than the current situation; there's just far too many setup guides and other documentation out there for us to expect all Debian/Ubuntu users to notice the additional step we might add to our own docs, even if it's in the package README and man pages. However, if we think that NSS-based network auth services are a thing of the past (as seems to be the upstream position on this), then maybe just adding docs is the right way to handle this.

I'm not too enthusiastic about option #2 either. While it would help with users of specific packages, without those users needing to know any specific details about the workaround, it won't cover all use cases - since we don't necessarily know all the different packages that might need to provide a drop-in - and also it could *add* confusion in some cases. For example, if someone is using a custom network-based libnss module, it would work on any system where they had the 'nis' package installed, but fail on any system where it wasn't installed - regardless of whether they are actually using nis for anything at all. That's the kind of thing that is incredibly painful to debug. This option also would require the 'nis' and 'libnss-ldap' packages to restart systemd-logind when they are installed, which (in the past at least) has sometimes been problematic.

I know that option #1 is kind of the 'worst', since it essentially just gives up and removes the restriction from systemd-logind for everyone. However, I personally think it's the best option. If/when we do start providing systemd-userdbd (and it's enabled by default), I think we should move the lifted restriction over to it, instead of systemd-logind. But for now we should just modify systemd-logind to allow network access, IMHO.

Since this is *theoretically* related to security, I'd like to get the Ubuntu security team's opinion on the change. I've cc'ed them on this bug.

@mbiebl, what do you think? I really don't know what the best approach is, either for Debian or for Ubuntu. And obviously, if you (or anyone) has other suggestions I'm happy to hear them.

And finally just FTR, I personally think upstream systemd should just remove the restriction (specifically, I mean remove IPAddressDeny=any) from systemd-userdbd.service. That service already funnels all systemd requests for user data into a single isolated process, I think it's overkill to also restrict that process from network access, when it's so common to have NSS-based network authentication mechanisms. However, Lennart's made his opinion known[1], and I'd prefer not to be the person who tries to argue with him to change his mind.

[1]: https://github.com/systemd/systemd/issues/15705#issuecomment-624125354