I included what on second thought is a somewhat broken fix for this in an upload of pam 1.4.0-3.
My fix is broken in that I got the upgrade and removal sequence of prerm confused (I thought prerm was called with remove <upgrading_to_version> on upgrade rather than <upgrade upgrading_to_version> on upgrade. So, my change has the affect of basically removing the pam-auth-update remove for unix when libpam-runtime is removed. It's wrong because it will do strange things if libpam-runtime is ever removed as part of a conflict relationship. I'll go fix it, but I need to figure out what the correct behavior is. The previous behavior was to remove the unix module's configuration, which as Josh points out generally creates an infinite loop. I'm honestly not convinced that's correct because all the pam-auth-update mechanisms live in libpam-runtime. Removing libpam-runtime is not a very supported configuration. Your pam stack basically isn't going to work--at least not in the standard Debian way. Josh wants purge to work. In the purge case it doesn't matter what we call pam-auth-update with because we're about to blow away its database anyway. Josh points out we could generate a pam-auth-update config effectively with pam_deny.so to at least fail secure. I'm not really interested in writing extra code for the removing an essential package case. My current thinking is that it's always wrong to pam-auth-update remove unix and that the prerm block could just be commented out. My rationale is taht if you're going to end up with a broken pam configuration it might as well be a broken pam configuration that references pam_unix.so even if pam_unix.so later gets removed. Unless I hear from someone that's the direction I'll take in the next upload. The current code is brokenish but has the same affect as never pam-auth-update removing pam_unix except in the currently non-existent case where libpam-runtime is removed as part of a conflict. --Sam
signature.asc
Description: PGP signature
