pam_succeed_if: prevent logging unknown user names in plaintext

[lzwind]

Summary

• When a user accidentally types their password at the username prompt, pam_succeed_if logs the password in plaintext via pam_syslog. This happens because evaluate_ingroup, evaluate_notingroup, evaluate_innetgr, and evaluate_notinnetgr return PAM_AUTH_ERR or PAM_SUCCESS for non-existent users instead of PAM_USER_UNKNOWN, bypassing the existing log guard (ret != PAM_USER_UNKNOWN).
• Instead of changing the return values of the evaluate_* functions (which would break the expected semantics, e.g., evaluate_notingroup should return PAM_SUCCESS when the user is not in the group), this fix modifies the logging part: check whether the user exists using pam_modutil_getpwnam(). If the user does not exist and audit is not enabled, print "unknown user" instead of the potentially sensitive user input.

Changes

File	Change
modules/pam_succeed_if/pam_succeed_if.c	After evaluate(), check if user exists via pam_modutil_getpwnam(). Use "unknown user" in log messages when user does not exist and audit is disabled.

Test plan

• Verify that when a non-existent username (e.g., a mistyped password) is passed to pam_succeed_if.so user ingroup <group>, logs show "unknown user" instead of the password
• Verify that existing valid user checks still work correctly (user name appears in logs as before)
• Verify that ingroup, notingroup, innetgr, notinnetgr qualifiers all behave correctly with both existing and non-existing users
• Verify that when audit flag is set, the actual user input is still logged for debugging purposes

Fixes: #559

[ldv-alt]

Looks like the chosen approach is not correct. Instead, I suggest changing the logging part where the user name is printed: if audit is enabled or the user exists, print the user name as it is printed now, otherwise print an unknown user.