> Thus I am much more convinced now that switching to common-session-noninteractive is not only correct (and also fixing this bug), but also not actually that regression prone.
To prove this:
$ diff -u /etc/pam.d/common-session{-noninteractive,}
@@ -27,5 +27,6 @@
session optional pam_umask.so
# and here are more per-package modules (the "Additional" block)
session required pam_unix.so
+session optional pam_systemd.so
session optional pam_ecryptfs.so unwrap
# end of pam-auth-update config
(the other two hunks are just comments). I. e. the only difference between (non)interactive is pam_systemd, which was a no-op under upstart/session-centric model due to the "already running in a session" check.
> Thus I am much more convinced now that switching to common- session- noninteractive is not only correct (and also fixing this bug), but also not actually that regression prone.
To prove this:
$ diff -u /etc/pam. d/common- session{ -noninteractive ,}
@@ -27,5 +27,6 @@
session optional pam_umask.so
# and here are more per-package modules (the "Additional" block)
session required pam_unix.so
+session optional pam_systemd.so
session optional pam_ecryptfs.so unwrap
# end of pam-auth-update config
(the other two hunks are just comments). I. e. the only difference between (non)interactive is pam_systemd, which was a no-op under upstart/ session- centric model due to the "already running in a session" check.