2026-09-29 12:47 UTC
@ska@social.treehouse.systems
In GUI programming terms:
The pam_conv function is expected to bring up a dialogue box, populate it with labels and entryfields from the passed-in messages array, do the ShowDialog() thing for a modal dialogue, populate the results array from the entryfields, and return.
Whereas the modeless dialogue approach involves #PAM requesting a CreateDialog() and the primary event loop calling PAM with the results when OK/Cancel are triggered.
From what you describe, you're on the right track.
Replies (1)
-
@JdeBP@tty0.social 2026-09-29 13:23
@ska@social.treehouse.systems This would involve completely turning #OpenPAM's whole 'authenticate' pathway inside out. It would have to become event driven with a state machine. But it's pretty terrible at the moment anyway. For starters: The API that apps have to implement is capable of prompting for username and password in one go, and even the dumb openpam_tty_conv() function can handle this. But pam_unix's 'authenticate' pathway prompts for account and password separately. https://cgit.freebsd.org/src/tree/contrib/openpam/modules/pam_unix/pam_unix.c#n64