[phucvinh57]

Summary

Users upgrading from 1.4.2 keep the old auth sufficient libbiopass_pam.so line in /etc/pam.d/common-auth, because postinst only ran ldconfig, so the [success=end default=ignore] profile from #226 never reached them. postinst now runs pam-auth-update --package on configure, the same call libpam-fprintd's postinst makes. Follow-up to #226 (known gap listed there).

Closes: N/A / Discussion: #221

Changes

Install scripts:

• app/src-tauri/scripts/deb/postinst: on configure, after ldconfig, run pam-auth-update --package if the command exists. --package only re-renders profiles that are already enabled; it never enables a Default: no profile such as ours, so the opt-in policy is unchanged. From /usr/sbin/pam-auth-update: --package only sets $package and lowers the prompt priority; the enabled list comes from the current common-* files; the only profiles added are Default eq 'yes' ones not seen before. Hand-edited common-* files are left alone ("Local modifications ... not updating", exit 0).
• If pam-auth-update itself fails, postinst fails (set -e), as libpam-fprintd's does.

Verification

Scratch root only (unshare --map-root-user, pam-auth-update --root <scratch>, private debconf DB; host /etc/pam.d not touched):

=== (1) 1.4.2 profile enabled, then upgrade
--- before (1.4.2):
auth	sufficient	libbiopass_pam.so
auth	[success=2 default=ignore]	pam_unix.so nullok try_first_pass
--- after pam-auth-update --package:
auth	[success=3 default=ignore]	libbiopass_pam.so
auth	[success=2 default=ignore]	pam_unix.so nullok try_first_pass
=== (2a) 1.4.2 profile installed and seen, not enabled, then upgrade
before/after identical: no libbiopass line
=== (2b) profile never seen by pam-auth-update, not enabled, then install
before/after identical: no libbiopass line (biopass now listed in /var/lib/pam/seen)

Argument handling (stubbed ldconfig and pam-auth-update):

postinst configure:          stub: ldconfig / stub: pam-auth-update --package  rc=0
postinst abort-upgrade:      rc=0   (no calls)
postinst abort-remove:       rc=0
postinst abort-deconfigure:  rc=0
configure without pam-auth-update: stub: ldconfig  rc=0
configure, pam-auth-update fails:  stub: ldconfig  rc=3

bash -n OK; checkbashisms -f -p rc=0. shellcheck runs in CI.

Manual testing:

Distro / version	Package (.deb/.rpm/AUR/source)	DE / display manager	Hardware (camera, IR, fingerprint)	Flow tested (login, sudo, polkit, lock screen, app)	Result

Not tested: a real dpkg -i upgrade from 1.4.2 in a VM (debconf prompt as users see it; with --package it is medium priority, hidden at the default high priority), and the rpm path (no change there; Fedora uses authselect).

Review report

Small root-run script change. Reviewed by the author against /usr/sbin/pam-auth-update (quoted above) and libpam-fprintd's postinst. The earlier security review of #226 flagged this gap ("upgrading users keep the old sufficient line") as minor.

Risk

• Low: docs, UI copy, styling, tests
• Medium: app logic, Rust/Tauri commands, face/fingerprint pipeline
• High: PAM module or helper, install/remove scripts, PAM config, packaging, CI/release workflows

What could break, and for whom: deb installs/upgrades on Debian/Ubuntu: if pam-auth-update fails, package configuration fails (same as libpam-fprintd). Admins who hand-edited common-* keep their files.

How to revert

git revert and a new release. Users who already got the new line keep it (it is the intended line); nothing else to undo.

Checklist

• I read the whole diff and can explain every change.
• Verification above shows real output, not a claim.
• All Important review findings are fixed or answered.
• Docs are updated if behavior, install, packaging, or distro support changed.