Don't cancel in-progress authentication on suspend
Since 6.0 (adfae584) the greeter cancels the in-progress PAM conversation when the system suspends. Aborting the conversation makes pam_authenticate() return a failure, which has two bad effects:
- On resume the greeter reports a failed login attempt the user never made.
- With pam_faillock (or similar) in the auth stack, the aborted conversation is recorded as a real failed attempt counting toward account lockout. Suspending a few times with the lock screen up can lock the account out.
This became much more visible in 6.7: before 9e622c86 the cancel was done by the greeter's own suspend wrapper, so it only applied to sleeps initiated from the lock screen UI; lid-close and other externally triggered suspends left the conversation alone. 9e622c86 replaced that wrapper with a watch on logind's PrepareForSleep signal, which fires for every suspend, so closing the lid on a locked machine now aborts the conversation too.
Instead, leave the conversation parked across suspend/resume — the behaviour all externally triggered sleeps had before 6.7 and all sleeps had before 6.0: on wake the prompt resumes where it was and a correct password ompletes normally.
BUG: 481808 FIXED-IN: 6.7.3
I couldn't find any justification for why the cancel was introduced in the first place, the commit introducing it didn't seem super related. I might totally be missing something about why that cancel is needed though. I tried some other changes involving doing the cancel, but marking in a global variable that it was a cancel and not a failure, and was able to stop the fail delay in the callback that way, but it still incremented the faillock counter, so it wasn't a great solution.
Disclosure: I used some AI in preparing this MR, but I made this change on 6.7.2 (version currently packaged for Arch) tested it on two of own machines, and have been driving that code since. I also reviewed and reasoned about the diffs myself, and read the relevant commits introducing the behavior.