** Description changed:

  [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 isn't actually a bug in systemd, this is a by-design security feature; 
see links below (and/or comment 13 in this bug) to upstream comments about how 
systemd's position is that no NSS module should ever perform network access, 
and any NSS module that does needs to also adjust the restrictions of systemd 
services such as systemd-logind, systemd-userdbd, and possibly others that 
might need to make NSS calls into glibc.
+ https://github.com/systemd/systemd/issues/7074#issuecomment-338157851
+ https://github.com/systemd/systemd/issues/15705#issuecomment-624125354
  
- this also can cause systemd-udevd failures in some cases as well,
- apparently (based on upstream and debian discussion comments)
+ this may also can cause systemd-udevd failures in some cases as well.
+ https://github.com/systemd/systemd/pull/7343#issuecomment-344800313
  
  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

-- 
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:
  Confirmed
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; 
see links below (and/or comment 13 in this bug) to upstream comments about how 
systemd's position is that no NSS module should ever perform network access, 
and any NSS module that does needs to also adjust the restrictions of systemd 
services such as systemd-logind, systemd-userdbd, and possibly others that 
might need to make NSS calls into glibc.
  https://github.com/systemd/systemd/issues/7074#issuecomment-338157851
  https://github.com/systemd/systemd/issues/15705#issuecomment-624125354

  this may also can cause systemd-udevd failures in some cases as well.
  https://github.com/systemd/systemd/pull/7343#issuecomment-344800313

  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     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to