Bug#990957: unblock: pam/1.4.0-9
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: vorlon@debian.org, henrich@debian.org
Please unblock package pam
(Please provide enough (but not too much) information to help
the release team to judge the request efficiently. E.g. by
filling in the sections below.)
[ Reason ]
As part of refreshing patches for PAM 1.4.0, we accidentally disabled support for the non-multiarch path for /lib/security. This patch brings back support for loading pam modules in /lib/security.
[ Impact ]
At a minimum, the following pam-modules will be completely ineffective
and will do nothing if installed:
libpam-apparmor: /lib/security/pam_apparmor.so
libpam-barada: /lib/security/pam_barada.so
libpam-biometric: /lib/security/pam_biometric.so
libpam-blue: /lib/security/pam_blue.so
libpam-freerdp2: /lib/security/pam_freerdp2.so
libpam-otpw: /lib/security/pam_otpw.so
libpam-pgsql: /lib/security/pam_pgsql.so
libpam-shield: /lib/security/pam_shield.so
libpam-slurm: /lib/security/pam_slurm.so
libpam-slurm-adopt: /lib/security/pam_slurm_adopt.so
libpam-tacplus: /lib/security/pam_tacplus.so
libpam-x2go: /lib/security/pam_x2go.so
libpam-yubico: /lib/security/pam_yubico.so
virtualbox-guest-utils: /lib/security/pam_vbox.so
[ Tests ]
PAM has no automated tests at the packaging level.
I confirmed without the patch that libpam-yubico failed to load and that with the patch libpam-yubico didn't give a module load error.
I did not properly configure and test libpam-yubico.
I confirmed that even with the patch, /lib/security/pam_unix.so does not mask /lib/x86_64-linux-gnu/security/pam_unix.so
[ Risks ] The patch looks relatively simple, it's been reviewed by
myself and by the person who submitted it. Even so, PAM is an
essential package, and if you take a look at the changelog for -9,
it's possible to get even a patch this simple wrong.
However, that's a lot of pam modules to have a grave your module doesn't work at all bug.
If you do grant the unblock, please add aging hints so the new PAM makes it in.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[] attach debdiff against the package in testing
[ Other info ]
(Anything else the release team should know.)
unblock pam/1.4.0-9
diff --git a/debian/changelog b/debian/changelog
index 03358422..dee3f32b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,36 @@
+pam (1.4.0-9) unstable; urgency=medium
+
+ * Revert prefer the multiarch path from 1.4.0-8: It turns out that
+ Debian uses DEFAULT_MODULE_PATH and _PAM_ISA in the opposite meaning
+ of upstream. If I had read the patch header of
+ patches-applied/lib_security_multiarch_compat more closely I would
+ have noticed this. The effect of 1.4.0-9 is what is stated in the
+ 1.4.0-8 changelog: we prefer multiarch paths, but the original patch
+ did that.
+ * I did test this in 1.4.0-8, but my test design was flawed. I placed a
+ invalid shared object in /lib/security and confirmed it did not shadow
+ an object in /lib/x86_64-linux-gnu/security. However I realized
+ shortly after releasing 1.4.0-8 that a valid shared object in
+ /lib/security will shadow one in the multiarch path.
+
+ -- Sam Hartman <hartmans@debian.org> Fri, 09 Jul 2021 10:55:02 -0600
+
+pam (1.4.0-8) unstable; urgency=high
+
+ [ Hideki Yamane ]
+ * debian/patches-applied/lib_security_multiarch_compat
+ - Fix regression introduced in 1.4.0-1: search both /lib/security and
+ /lib/[multiarch_tripple]/security/, Closes: #990790
+
+ [ Sam Hartman ]
+ * Reword changelog
+ * Prefer the multiarch path (_PAM_ISA) to the non-multiarch path.
+ That's different than buster, but guarantees everything already
+ working in bullseye will continue to work and also guarantees that
+ when multiarch modules are available we use them.
+
+ -- Hideki Yamane <henrich@debian.org> Tue, 06 Jul 2021 22:09:15 +0900
+
pam (1.4.0-7) unstable; urgency=medium
* Updated portuguese debconf translation, thanks Pedro Ribeiro, Closes:
diff --git a/debian/patches-applied/lib_security_multiarch_compat b/debian/patches-applied/lib_security_multiarch_compat
index c43a733e..e386ff39 100644
--- a/debian/patches-applied/lib_security_multiarch_compat
+++ b/debian/patches-applied/lib_security_multiarch_compat
@@ -11,11 +11,11 @@ currently abusing the existing variables and inverting their meaning in
order to get everything installed where we want it and get absolute paths
the way we want them.
-Index: pam/libpam/pam_handlers.c
+Index: pam-1.4.0/libpam/pam_handlers.c
===================================================================
---- pam.orig/libpam/pam_handlers.c
-+++ pam/libpam/pam_handlers.c
-@@ -735,7 +735,18 @@
+--- pam-1.4.0.orig/libpam/pam_handlers.c
++++ pam-1.4.0/libpam/pam_handlers.c
+@@ -735,7 +735,27 @@ _pam_load_module(pam_handle_t *pamh, con
success = PAM_ABORT;
D(("_pam_load_module: _pam_dlopen(%s)", mod_path));
@@ -31,11 +31,20 @@ Index: pam/libpam/pam_handlers.c
+ } else {
+ pam_syslog(pamh, LOG_CRIT, "cannot malloc full mod path");
+ }
++ if (!mod->dl_handle) {
++ if (asprintf(&mod_full_path, "%s/%s",
++ _PAM_ISA, mod_path) >= 0) {
++ mod->dl_handle = _pam_dlopen(mod_full_path);
++ _pam_drop(mod_full_path);
++ } else {
++ pam_syslog(pamh, LOG_CRIT, "cannot malloc full mod path");
++ }
++ }
+ }
D(("_pam_load_module: _pam_dlopen'ed"));
D(("_pam_load_module: dlopen'ed"));
if (mod->dl_handle == NULL) {
-@@ -812,7 +823,6 @@
+@@ -812,7 +832,6 @@ int _pam_add_handler(pam_handle_t *pamh
struct handler **handler_p2;
struct handlers *the_handlers;
const char *sym, *sym2;
@@ -43,7 +52,7 @@ Index: pam/libpam/pam_handlers.c
servicefn func, func2;
int mod_type = PAM_MT_FAULTY_MOD;
-@@ -824,16 +834,7 @@
+@@ -824,16 +843,7 @@ int _pam_add_handler(pam_handle_t *pamh
if ((handler_type == PAM_HT_MODULE || handler_type == PAM_HT_SILENT_MODULE) &&
mod_path != NULL) {
Reply to: