Bug#990412: pam: Regression - it won't search /lib/security
> "Steve" == Steve Langasek writes: Steve> For the record, I did not intentionally drop those lines, Steve> this was a matter of a mis-merge. Okay, if it was a miss-merge, let's see if we can fix. I'm reasonably busy this morning but will try to prepare something later today based on the patch Hideki proposed. I know I'm going to phrase the changelog entry differently, but will credit Hideki and use that patch as a starting point.
Bug#990412: pam: Regression - it won't search /lib/security
On Tue, Jul 06, 2021 at 08:46:30AM -0600, Sam Hartman wrote: > > "Hideki" == Hideki Yamane writes: > control: tags -1 -patch -pending > I NACK this proposed NMU. > This many years after multiarch, I think it is entirely reasonable for > PAM to drop support for non-multiarch paths at the transition between > buster and bullseye. > As I said earlier in the bug, I'm happy to add breaks on libpam-yubico > or other packages as necessary. > I think Steve is quite familiar with multiarch and while he hasn't > commented yet I'm assuming he dropped those patch lines as part of > removing unnecessary upstream deltas. > I think you failed to read my comments in the 990412 bug log before > Merging and reassigning. For the record, I did not intentionally drop those lines, this was a matter of a mis-merge. My only concern about dropping support for the legacy path is that this is an API that may be used by third-party software, not just by Debian packages. I'm ok with requiring all Debian packages to use the multiarch path for PAM modules, provided libpam0g then also declares a Breaks: against older versions of those packages which use the legacy path. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#990412: pam: Regression - it won't search /lib/security
> "Hideki" == Hideki Yamane writes: >> I think Steve is quite familiar with multiarch and while he >> hasn't commented yet I'm assuming he dropped those patch lines as >> part of removing unnecessary upstream deltas. Hideki> I want his comment, too. Okay, let's hold off until Steve speaks up then. Meanwhile, I definitely think we should fix libpam-yubico any other PAM modules we ideftify. PAM modules need to be multi-arch so that if any non-native application calls libpam, it works. So there's at least an important if not serious bug in not having multi-arch:same for a PAM module. signature.asc Description: PGP signature
Bug#990412: pam: Regression - it won't search /lib/security
Hi Sam, On Tue, 06 Jul 2021 08:46:30 -0600 Sam Hartman wrote: > This many years after multiarch, I think it is entirely reasonable for > PAM to drop support for non-multiarch paths at the transition between > buster and bullseye. It was NOT raised as a goal of bullseye for libpam-* packages those are not multiarch-ed, IMO. And at this time, last minutes for release, we should ensure "it works" as previously to deliver values for users. Breaking several libpam-* packages is not. Is there any *strong* reason to not deffer make libpam-* packages multiarch-ed to bookworm release? > I think Steve is quite familiar with multiarch and while he hasn't > commented yet I'm assuming he dropped those patch lines as part of > removing unnecessary upstream deltas. I want his comment, too. git log in his repo just says "refresh patches" for this change, and debian/patches-applied/lib_security_multiarch_compat is the patch for non-multiarch pam modules and still remains. If it was intended, it should be removed, I suppose. > I think you failed to read my comments in the 990412 bug log before > Merging and reassigning. Okay, will read again. Thanks! -- Hideki Yamane
Bug#990412: pam: Regression - it won't search /lib/security
> "Hideki" == Hideki Yamane writes: control: tags -1 -patch -pending I NACK this proposed NMU. This many years after multiarch, I think it is entirely reasonable for PAM to drop support for non-multiarch paths at the transition between buster and bullseye. As I said earlier in the bug, I'm happy to add breaks on libpam-yubico or other packages as necessary. I think Steve is quite familiar with multiarch and while he hasn't commented yet I'm assuming he dropped those patch lines as part of removing unnecessary upstream deltas. I think you failed to read my comments in the 990412 bug log before Merging and reassigning. signature.asc Description: PGP signature
Bug#990412: pam: Regression - it won't search /lib/security
control: tags -1 +patch +pending
Hi,
I've found the root cause of this bug, and fixed it.
On my local sid machine, I've tested it with edit /etc/pam.d/su
as search pam_yubico.so, exec su and it searchs /lib/security/pam_yubico.so :)
See below debdiff. If it seems to be okay, I'll put it into sid
and request unblock.
diff -Nru pam-1.4.0/debian/changelog pam-1.4.0/debian/changelog
--- pam-1.4.0/debian/changelog 2021-03-16 04:01:55.0 +0900
+++ pam-1.4.0/debian/changelog 2021-07-06 22:09:15.0 +0900
@@ -1,3 +1,13 @@
+pam (1.4.0-7.1) unstable; urgency=high
+
+ * Non-maintainer upload.
+ * debian/patches-applied/lib_security_multiarch_compat
+- Fix regression that was introduced in 1.4.0-1, some lines were not
+ applied during refresh patch and it doesn't work.
+ (Closes: #979973, #990412)
+
+ -- Hideki Yamane 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 -Nru pam-1.4.0/debian/patches-applied/lib_security_multiarch_compat
pam-1.4.0/debian/patches-applied/lib_security_multiarch_compat
--- pam-1.4.0/debian/patches-applied/lib_security_multiarch_compat
2021-01-31 07:09:52.0 +0900
+++ pam-1.4.0/debian/patches-applied/lib_security_multiarch_compat
2021-07-06 22:09:15.0 +0900
@@ -11,11 +11,11 @@
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 @@
+ } else {
+ pam_syslog(pamh, LOG_CRIT, "cannot malloc full mod path");
+ }
++ if (!mod->dl_handle) {
++ if (asprintf(_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 @@
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) {
