scheduler: Raise auth failure log level from DEBUG to WARN for fail2ban compatibility#1561
Conversation
|
Hi @michaelrsweet Sir, I have submitted PR #[PR 1561] for this issue. I have updated the PR to ensure consistent log messaging across the scheduler. I also fixed the argument count in the log calls to match the format strings. Ready for review! |
michaelrsweet
left a comment
michaelrsweet
left a comment
There was a problem hiding this comment.
Some minor changes here, then I can work on the OAuth and Kerberos messaging to match.
| if (pamerr != PAM_SUCCESS) | ||
| { | ||
| cupsdLogClient(con, CUPSD_LOG_ERROR, "pam_authenticate() returned %d (%s)", pamerr, pam_strerror(pamh, pamerr)); | ||
| cupsdLogClient(con, CUPSD_LOG_WARN, "Authentication failed for user \"%s\" from %s", username, con->http->hostname); |
There was a problem hiding this comment.
I think I'd rather combine these into a single ERROR message; maybe we can standardize the wording here and for the other methods, something like:
Authentication failed for user \"%s\" from %s (%s)
where the message in parens is the error.
| */ | ||
|
|
||
| cupsdLogMessage(CUPSD_LOG_DEBUG, "cupsdIsAuthorized: User not in group(s)."); | ||
| cupsdLogMessage(CUPSD_LOG_WARN, "cupsdIsAuthorized: User not in group(s)."); |
There was a problem hiding this comment.
This could be:
Authentication failed for user \"%s\" from %s (Not in group.)
|
Hi @michaelrsweet Sir, I have updated PR #1561 as per your review comments. Both auth failure messages now use ERROR level with standardized wording including username and hostname. pam_end() call is also preserved. Please review! |
2 participants
Fixes #1553
When LogLevel is set to "error" in cupsd.conf, authentication
failure messages were logged at CUPSD_LOG_DEBUG level and never
appeared in logs. This prevented fail2ban from detecting failed
login attempts and blocked brute force protection.
This change raises the log level from CUPSD_LOG_DEBUG to
CUPSD_LOG_WARN for the "User not in group(s)" message in
scheduler/auth.c, ensuring it appears in logs regardless of
the configured LogLevel.