Alright, to the source code we go!
login program is in charge by the time my login prompt appears. Let's start there, more specifically in the
login appears to be in charge of the
login prompt, since it generates it in
loginpam_get_prompt and registers it with PAM in
loginpam_auth function then takes over, and control goes to PAM's
pam_authenticate function. This means that
login merely defines a prompt for the username and that's it.
To PAM then: what we're interested in clearly happens in
The pam_authenticate function is used to authenticate the user. The user is required to provide an authentication token depending upon the authentication service, usually this is a password, but could also be a finger print.
Now, shadow-based authentication (
/etc/shadow) is handled by the
pam_unix module. My distribution (Arch) provides PAM through the
pam package, which means our journey continues over to linux-pam.org and its source code.
modules/pam_unix/pam_unix_auth.c seems a good place to start. PAM modules provide their authentication mechanism through a
pam_sm_authenticate function, which we find here. The password (or "authentication token", see above) is fetched with a call to PAM's
pam_get_authtok function. It is declared in the
security/pam_ext.h header file, so that's where we're going next.
extern int PAM_NONNULL((1,3))
pam_get_authtok (pam_handle_t *pamh,
const char **authtok,
const char *prompt);
Nothing too promising in those arguments but well... Let's see the definition.
NULL for the
prompt argument and
item, so we end up here. Now that hardcoded
PAM_PROMPT_ECHO_OFF given to
pam_prompt just doesn't look good for me...
retval = pam_prompt (pamh, PAM_PROMPT_ECHO_OFF, &resp, "%s", PROMPT);
By the way, the password
PROMPT is also hardcoded (here), so there goes my dream of a more exotic password prompt... Anyway, let's go over to the
pam_prompt function. The actual prompt happens here, where PAM calls a conversation function fetched a few lines above. A quick look at the
pam_set_item functions introduces us to the
pam_conv structure defined here.
Now, finding information on the default PAM conversation function was a lot trickier than it should be (I think). Everywhere I looked, the structure remained uninitialised and
pam_unix does not appear to define its own. However I managed to find the generic
misc_conv function, which passes
PAM_PROMPT_ECHO_OFF over to
read_string and... here's where PAM deactivates input feedback.
Conclusion: the absence of password feedback is hardcoded. Too bad. A little digging got me to this GitHub issue and this Arch BBS thread. Apparently, the feature was available back when PAM wasn't a standard for authentication. I guess it makes sense not to have implemented it again - security and all - but you know, an option would have been nice.
Anyway, I've just ordered my new keyboard.