Bugzilla will be upgraded to version 5.0 on December 2, 2018. The outage period for the upgrade will start at 0:00 UTC and have a duration of 12 hours
Bug 124979 - pam_succeed_if.so generates noisy secure syslog msgs
pam_succeed_if.so generates noisy secure syslog msgs
Product: Fedora
Classification: Fedora
Component: pam (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
: FutureFeature
: 152061 158103 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2004-06-01 15:19 EDT by Scott Moorhouse
Modified: 2007-11-30 17:10 EST (History)
9 users (show)

See Also:
Fixed In Version: pam-0.77-56
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-22 03:45:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
Description Scott Moorhouse 2004-06-01 15:19:33 EDT
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):
Comment 1 Mike Chambers 2004-06-09 18:38:40 EDT
I got the same message last night as well, but my pam version is a tad

Comment 2 Matthew Miller 2004-06-09 23:41:17 EDT
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 11:30:05 EDT
You make a good point, Matthew.  log_pass, log_fail, log_both maybe?
Comment 4 Nalin Dahyabhai 2004-06-10 16:06:35 EDT
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-07 20:28:37 EDT
See also bug 55193 where this noise was introduced.
Comment 6 Tomas Mraz 2004-09-10 03:49:21 EDT
Created attachment 103674 [details]
Comment 7 Tomas Mraz 2004-09-10 03:51:35 EDT
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 03:59:58 EDT
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 01:24:04 EST
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
Comment 10 Scott Moorhouse 2004-12-23 12:40:48 EST
These module parameters did not make it into the pam_succeed_if
manpage in the FC3 release.
Comment 11 Tomas Mraz 2004-12-25 14:55:41 EST
Yes, please open a new bug for that issue.
Comment 12 Tomas Mraz 2005-03-24 13:04:42 EST
*** Bug 152061 has been marked as a duplicate of this bug. ***
Comment 13 Tomas Mraz 2005-05-18 14:21:10 EDT
*** 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.