Other than the obvious approach of enabling systemd-userdb for Ubuntu, which is a much larger discussion/decision, I think there are really only 2 ways to address this:
1) Include drop-in conf files for systemd-logind and systemd-udevd to remove the networking sandbox 2) add configuration documentation to nis and openldap instructing the system admin to create drop-in conf files for systemd-logind and systemd-udevd as part of system configuration Option #1 has the advantage of 'just working' without any local admin changing anything, but has the disadvantage of completely removing network sandboxing for logind/udevd. Option #2 has the advantage of keeping the sandboxing and allowing the admin to customize it more specifically, such as allowing networking only to specific nis/ldap servers instead of allowing all networking, but has the disadvantage of requiring the system admin to read the docs and actually perform the additional configuration. I'm skeptical of option #1 as the network sandboxing is a security feature, but also I'm pretty sure if we go with option #2 there will be plenty more bugs opened due to admins missing that part of the local system configuration. Any opinions or other ideas on approaches? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1934393 Title: systemd-logind network access is blocked, and breaks remote authentication configurations Status in systemd: Fix Released Status in nis package in Ubuntu: Confirmed Status in openldap package in Ubuntu: New Status in systemd package in Ubuntu: Won't Fix Status in nis package in Debian: Fix Released Bug description: [impact] starting in focal, systemd-logind runs sandboxed without any network access, which breaks any configuration that uses remote servers for user data, e.g. ldap, nis, etc A more full discussion is available in the upstream bug report as well as the debian bug report, see other info section below [test case] many possible ways to reproduce this; there are reproducers in some of the bugs reported before that are caused by this, e.g. bug 1915502 or bug 1916235 [regression potential] failure to authenticate when using remote user data, incorrect authentication, security issues due to un-sandboxing of systemd-logind [scope] this is needed in f and later before focal, systemd-logind was not sandboxed so this did not apply [other info] this isn't actually a bug in systemd, this is a by-design security feature, and the intended upstream design is for systemd-logind to talk to systemd-userdb, so that systemd-logind can remain network- sandboxed while systemd-userdb performs any needed network access for user/auth data. However, Debian and Ubuntu don't enable/provide systemd-userdb, so that design does not work for Debian/Ubuntu. this also can cause systemd-udevd failures in some cases as well, apparently (based on upstream and debian discussion comments) For reference, upstream discussion around the systemd-logind sandboxing specifically: https://github.com/systemd/systemd/issues/7074 upstream updated doc PR explaining the upstream position: https://github.com/systemd/systemd/pull/7343 Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878625 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1934393/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
