Dear Maintainer,

It appears that in Bullseye pam isn't checking /lib/security.

The libpam-yubico package installes a module in /lib/security which when
configured without an absolute path pam errors with:

PAM unable to dlopen(pam_yubico.so):
/lib/x86_64-linux-gnu/security/pam_yubico.so: cannot open shared object
file: No such file or directory

This worked fine on Buster, it also works on the latest Ubuntu.

lib-pamyubico bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979973

control: reassign -1 libpam-yubico
control: severity -1 grave
control: retitle -1 pam_yubico fails to install module in multiarch path
control: found -1 2.23-1

    Rowan> It appears that in Bullseye pam isn't checking /lib/security.

    Rowan> The libpam-yubico package installes a module in /lib/security
    Rowan> which when configured without an absolute path pam errors
    Rowan> with:

I think that's a bug in the other package.
The issue is that /lib/security is not a multiarch path.
And so I cannot have both an i386 and amd64 version of the module
installed at the same time.
By this point, we really ought to be supporting multiarch.

I'm happy to add breaks relationships in pam on broken modules that
don't provide multiarch paths,
but I'd consider this a grave bug on a module that only installs in
/lib/security at this point.

control: reassign -1 libpam-yubico
control: severity -1 grave
control: retitle -1 pam_yubico fails to install module in multiarch path
control: found -1 2.23-1

    Rowan> It appears that in Bullseye pam isn't checking /lib/security.

    Rowan> The libpam-yubico package installes a module in /lib/security
    Rowan> which when configured without an absolute path pam errors
    Rowan> with:

I think that's a bug in the other package.
The issue is that /lib/security is not a multiarch path.
And so I cannot have both an i386 and amd64 version of the module
installed at the same time.
By this point, we really ought to be supporting multiarch.

I'm happy to add breaks relationships in pam on broken modules that
don't provide multiarch paths,
but I'd consider this a grave bug on a module that only installs in
/lib/security at this point.

Fair enough, I couldn't find any docs on the policy of /lib/security or
any news on it not being scanned in Bullseye, is there something about
that somewhere?

Fair enough, I couldn't find any docs on the policy of /lib/security or
any news on it not being scanned in Bullseye, is there something about
that somewhere?

    Rowan> Fair enough, I couldn't find any docs on the policy of
    Rowan> /lib/security or any news on it not being scanned in
    Rowan> Bullseye, is there something about that somewhere?

I don't know.
I had mostly been not paying attention to PAM but it looked like Steve
was getting a bit behind and he accepted an offer of help.
So, I was not tracking when this change got made.
It may well be we should document this is release notes.

    Rowan> Fair enough, I couldn't find any docs on the policy of
    Rowan> /lib/security or any news on it not being scanned in
    Rowan> Bullseye, is there something about that somewhere?

I don't know.
I had mostly been not paying attention to PAM but it looked like Steve
was getting a bit behind and he accepted an offer of help.
So, I was not tracking when this change got made.
It may well be we should document this is release notes.

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.000000000 +0900
+++ pam-1.4.0/debian/changelog	2021-07-06 22:09:15.000000000 +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 <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 -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.000000000 +0900
+++ pam-1.4.0/debian/patches-applied/lib_security_multiarch_compat	2021-07-06 22:09:15.000000000 +0900
@@ -11,11 +11,11 @@
 order to get everything installed where we want it and get absolute paths
 the way we want them.

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.

Hi Sam,

 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 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.

 Okay, will read again. Thanks!

    >> 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.

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> 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.

control: clone -1 -2
control: retitle -2 mis-merge in patches prevents reading /lib/security
control: reassign -2 pam
control: found -2 1.4.0-1
control: severity -2 important
control: severity -1 serious

Steve said that it was not an intentional change to prevent finding pam
modules in /lib/security.  Steve also points out that /lib/security may
be used by software not in Debian.

The cloned bug will track reintroducing the feature based on Hideki's
patch.
I still believe there is a (probably RC) bug in PAM modules that don't
use multiarch paths.
In particular, if the user installs any application that edpends on PAM
and is not of the native architeture, things will break if there are
modules in /lib/security.
So, libpam-yubico and other PAM modules still need to get fixed, but we
will work to fix the regression in PAM too.

We believe that the bug you reported is fixed in the latest version of
yubico-pam, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 979973@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Patrick Winnertz <winnie@debian.org> (supplier of updated yubico-pam package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sat, 04 May 2024 13:48:35 +0200
Source: yubico-pam
Architecture: source
Version: 2.27-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Authentication Maintainers <pkg-auth-maintainers@lists.alioth.debian.org>
Changed-By: Patrick Winnertz <winnie@debian.org>
Closes: 979973 1064121 1066579
Changes:
 yubico-pam (2.27-1) unstable; urgency=medium
 .
   [Simon Josefsson]
   * New upstream version (Closes: #1066579)
   * Drop myself from Uploader's.
 .
   [Michael Biebl]
   * Install PAM module into multiarch path in /usr. (Closes: #1064121)
 .
   [Patrick Winnertz]
   * Bump debhelper dependency to 12
   * Add myself to the uploaders and remove both upstream authors
     from there after private discussion with Klas Lindfors
   * Library is installed in multiarch path (Closes: #979973)
   * Bump standards version to 4.7.0 - no changes needed.
   * Remove compat file and use build-depends instead.
   * Remove hardcoded depends which are not longer available and use the correct build-deps instead.
   * remove dh_install --fail-missing which was removed in compat level 12
   * Bump version of uscan to 4 - no further changes needed.
   * Use the same upstream-signing key mechanism as in the pam-u2f package.
Checksums-Sha1:
 f8107a95d38f6d03baef0b5cd0714bec47a66554 2393 yubico-pam_2.27-1.dsc
 398b2413e8e28329098e4f62bba278cb65d9f526 454512 yubico-pam_2.27.orig.tar.gz
 3a74c31582843799c57a1c0176c33c03717ec939 488 yubico-pam_2.27.orig.tar.gz.asc
 e6d280b2e8615ef488ba6da99ddc08bd7fb9a617 66480 yubico-pam_2.27-1.debian.tar.xz
 36dbb6587551334ac03d171786623d693bcc7ea1 7391 yubico-pam_2.27-1_amd64.buildinfo
Checksums-Sha256:
 4a4c4f2a221eeee855ed82358f5b00083d16010ff2055a11884d61bcba275bdf 2393 yubico-pam_2.27-1.dsc
 63d02788852644d871746e1a7a1d16c272c583c226f62576f5ad232a6a44e18c 454512 yubico-pam_2.27.orig.tar.gz
 ee1a304e4897fcb4e56d70dd941cd909a5888e159e568e1b43eb21f23e533f03 488 yubico-pam_2.27.orig.tar.gz.asc
 45b7ec0b0a9d9a184636e6748f8164030c3bf5eb82c24cee31c4ce60f0e39d88 66480 yubico-pam_2.27-1.debian.tar.xz
 21c748f543ce89d52daf2e3ac6c3d62bd466d56d2eea53c6f7a8ab8c421064d7 7391 yubico-pam_2.27-1_amd64.buildinfo
Files:
 e820742139afe6e936a5f1ecff1406c3 2393 admin optional yubico-pam_2.27-1.dsc
 7a8cbac9f60260a6298062717a2f43e1 454512 admin optional yubico-pam_2.27.orig.tar.gz
 5314776cb1b4e4f65b1e5b864d78310d 488 admin optional yubico-pam_2.27.orig.tar.gz.asc
 ba255f5d5f3ce1e9e91681647a10446a 66480 admin optional yubico-pam_2.27-1.debian.tar.xz
 aed2b3f42d9c7c08094d736135770364 7391 admin optional yubico-pam_2.27-1_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQJGBAEBCgAwFiEE8s7HdaJ514A0GZEJjUsraXJJeKIFAmY2JJcSHHdpbm5pZUBk
ZWJpYW4ub3JnAAoJEI1LK2lySXiiKukP/05FhlgmtMfQHfSMwaKkxyeDY+TpA1kx
iSNCb6okHOGMofLFGD/kmmmv8xD7Qm0yiREHknp8zw00oNvJ/8ccySzsmY68zYYJ
tuDTyI6cCuclKbUOuTIkp+8Ub82BSvEB/ZfLRfmMm4SME+/eWAdYhb2mOuwpnSGc
4/+DhuJYTvb2x0bN5fU8em1vkO0HUxeNwgXW/6ghIGCvem5q8VyUtqi9Knb53gja
Hs0CaIt99bOz4/nwwH5DOjTJPUciyg5n3QrP1HXrWdQrcQ9FrN47gWEFPWot8lB9
1Wo3pRP06vQujx/wfshMcYjK+lS5qLIPv8EIiMI90dfI+Z7tg53bw7KfQFEvt+/h
HYbrDRqRAxvjftAO0TBAKxGC4CeOGfCDcWkkOWgGfJVcOWXUz2mBIjrTPTHDwh26
KGI9gz99/1hyM+8iM9w9hr/oEzYC4roN49zk1MRrFzDA8z0Wka0pRR0jHWaLaP9l
HRmleutWXDpfFL3pJ6k8m8W2T6975KO3awpGeef73815sMpVbuScd3ryOWnF9Lpe
10Cy5n02oxnrAvWGj2Y1dyuTMgshT7g/OnUHgr0LPrLvl3h/50NsNOdUKmpjZn0z
Uq4ooT3WPXQIVB2KwIp6zeR3z8I3Vk0n1v1ojB09f9NjFKdMGmgURovcgsnWTDOI
cOrUv1MesMm5
=OUj/
-----END PGP SIGNATURE-----