Package: release.debian.org Severity: normal User: release.debian....@packages.debian.org Usertags: unblock X-Debbugs-Cc: vor...@debian.org, henr...@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 <hartm...@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 <henr...@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) {