Bug 124979 - pam_succeed_if.so generates noisy secure syslog msgs
Summary: pam_succeed_if.so generates noisy secure syslog msgs
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: pam
Version: 2
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact:
URL:
Whiteboard:
: 152061 158103 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-06-01 19:19 UTC by Scott Moorhouse
Modified: 2007-11-30 22:10 UTC (History)
9 users (show)

Fixed In Version: pam-0.77-56
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-09-22 07:45:36 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Pro (2.46 KB, patch)
2004-09-10 07:49 UTC, Tomas Mraz
no flags Details | Diff

Description Scott Moorhouse 2004-06-01 19:19:33 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040116

Description of problem:
By default, pam_succeed_if.so is the first module in the system-auth
account stack, checking if the userid is less than 100 (I assume to
avoid unneccessary name service lookups for system accounts?).  Each
time this stack is traversed for a non-system user, pam_succeed_if
generates an authpriv.info message:

pam_succeed_if: requirement "uid < 100" not met by user "username"

This will send an authpriv.info message every time a (non-system) user
logs into dovecot, for instance, if dovecot is configured to check
accounts with pam. This seems like a lot of log pollution for a
commonplace and benign activity.

Version-Release number of selected component (if applicable):
pam-0.77-40

Comment 1 Mike Chambers 2004-06-09 22:38:40 UTC
I got the same message last night as well, but my pam version is a tad
higher...

pam-0.77-44

Comment 2 Matthew Miller 2004-06-10 03:41:17 UTC
Hard to know what to do about this one -- obviously there are a lot of
cases where one would want to use this module and would very much want
success or failure to be logged.

Hmmm -- or maybe a flag which toggles whether success or failure is
logged? In this particular use, the interesting case is when the uid
*is* less than 100 -- not when the test fails.

Comment 3 Scott Moorhouse 2004-06-10 15:30:05 UTC
You make a good point, Matthew.  log_pass, log_fail, log_both maybe?


Comment 4 Nalin Dahyabhai 2004-06-10 20:06:35 UTC
I was leaning toward Scott's view, but Matthew's right that in many
cases you'd want that information logged.  Perhaps flags to quiet the
module would be better, since in this instance we don't care enough
either way, and authconfig can pick up a versioned dependency on
whichever pam package starts recognizing a "be more quiet" flag.

Comment 5 Kenneth Porter 2004-08-08 00:28:37 UTC
See also bug 55193 where this noise was introduced.

Comment 6 Tomas Mraz 2004-09-10 07:49:21 UTC
Created attachment 103674 [details]
Pro

Comment 7 Tomas Mraz 2004-09-10 07:51:35 UTC
For proposed patch see above.

I've added 3 obvious parameters to the module - quiet (don't log
success or failure), quiet_fail (don't log failure), quiet_success
(don't log success).


Comment 8 Tomas Mraz 2004-09-22 07:59:58 UTC
I have opened a new bug 133179 against authconfig to include the quiet
option for pam_succeed_if in system-auth file.


Comment 9 Moritz Naumann 2004-11-17 06:24:04 UTC
For an immediate workaround for people who do not need _any_ reports
on this, in /etc/log.d/conf/services/secure.conf add dovecot-auth to
$ignore_services

Comment 10 Scott Moorhouse 2004-12-23 17:40:48 UTC
These module parameters did not make it into the pam_succeed_if
manpage in the FC3 release.

Comment 11 Tomas Mraz 2004-12-25 19:55:41 UTC
Yes, please open a new bug for that issue.


Comment 12 Tomas Mraz 2005-03-24 18:04:42 UTC
*** Bug 152061 has been marked as a duplicate of this bug. ***

Comment 13 Tomas Mraz 2005-05-18 18:21:10 UTC
*** Bug 158103 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.