--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: Pam: Multiple issues Affecting Upgrades
- From: Sam Hartman <hartmans@debian.org>
- Date: Tue, 23 Feb 2021 13:17:13 -0500
- Message-id: <161410423247.435393.4360432393616437072.reportbug@mount-peerless>
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: vorlon@debian.org
Hi. I'm writing with my pam uploader hat on to give you a heads up about two issues that are kind of nasty and affect upgrades. This is just a FYI, opened as a bug because you've expressed a preference for that communication style.
Feel free to close now; if this is still open when I have an unblock ready, I'll close and file the unblock.
I hope to have something in experimental or unstable by end of this
week. Depending on my confidence in the fixes, I may be ready for an
unblock at that point, or I may want to ask for additional review
before I'm ready to recommend inclusion in testing.
* 982530: removal of pam_tally
Up through buster, there were pam_tally and pam_tally2 modules available to provide lockout.
These modules were not in the default configuration, but apparently various hardening guides turned them on.
They were deprecated upstream, and we've chosen to remove them from bullseye.
Unfortunately, if your pam config includes these modules, then probably you can't login until you boot with rescue media and fix the pam config.
Moreover, while you probably get reasonable errors in the journal, you probably can't see that because you can't log in.
Plan is to detect the situation and scream in the preinst.
Down side is that means new strings that need translation (debconf templates)
* 982295: pam won't deal with upgrades without an init script
Pam restarts various services on upgrade (including buster to bullseye). The consequence of not restarting can be segfaults or failed pam authentications going forward. (libpam-modules gets out of sync with libpam0g and ether fails to dlopen or segfaults depending).
The logic in libpam0g.postinst is init-script specific.
Our current policy allows init scripts to be removed, and apparently
various users and downstreams are removing init scripts even when the
package still contains them.
I'm testing a patch to use systemd facilities for doing restarts if booted with systemd as init.
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'testing'), (500, 'stable'), (200, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- End Message ---