Bug 165571 - LTC19418- pam_unix spams /var/log/messages on cron jobs
LTC19418- pam_unix spams /var/log/messages on cron jobs
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: pam (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
:
Depends On:
Blocks: 173926
  Show dependency treegraph
 
Reported: 2005-08-10 11:23 EDT by Rudi Chiarito
Modified: 2007-11-30 17:11 EST (History)
5 users (show)

See Also:
Fixed In Version: pam-0.99.6.2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-02-06 10:13:41 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Rudi Chiarito 2005-08-10 11:23:23 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6

Description of problem:
Every cron job will result in two syslog messages like this:

Aug 10 10:01:01 geneva crond(pam_unix)[369]: session opened for user root by (uid=0)
Aug 10 10:01:01 geneva crond(pam_unix)[369]: session closed for user root

It's already bad enough in the default installation, but if you run jobs every five or ten minutes, then things get out of hand. Some tools like mrtg can be run in daemon mode, but you're not always that lucky, see for example sysstat after you install its RPM. The vast majority of the text in /var/log/messages* will be pam_unix spam, which has very little useful information for the system administrator.

I have searched for solutions. One floated around is to disable the "session" statement in /etc/pam.d/crond. It didn't work for me and, even if it worked, it would still look very dubious to me. Another one is to redirect or silence the messages, which is easier said than done. Initially, one would assume that crond messages would all appear in /var/log/cron. Wrong. That's not the case for the session messages, as they are created by pam_unix and their type is auth.info. It makes sense if you think about it for a while. Matching parts of the message is resource intensive; so you don't want syslogd do that. You probably don't want to redirect auth.* to a new /var/log/auth, either - or do you? You definitely to want to silence auth.info message altogether.

Would it make sense to have pam_unix be able to send syslog messages with a different facility? E.g. some way in /etc/pam.d/crond to tell pam_unix to spew out cron.info syslog messages instead, so that the spam ends up in /var/log/cron, where it is more "on-topic" (even if it's really an auth notification).


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

How reproducible:
Always

Steps to Reproduce:
1. yum install sysstat (or yum install mrtg - from Extras)

Actual Results:  /var/log/messages gets cluttered with pam_unix noise

Expected Results:  pam_unix noise should be in /var/log/cron or some other log file

Additional info:
Comment 1 Damian Menscher 2005-08-18 04:58:25 EDT
Seeing this in RHEL 4 also; most junk a result of the sysstat package, which has
a */10 minute cronjob.  Makes logs fairly unreadable.
Comment 2 Tomas Mraz 2005-09-08 14:15:46 EDT
This can be resolved only by adding "quiet" option to pam_unix for session
calls.  Then you could modify /etc/pam.d/system-auth to silence these messages.
Comment 4 Tomas Mraz 2005-10-21 18:16:31 EDT
I have better idea but it would have to be accepted upstream first and it would
require modification of pam patch in the cron.

A PAM_LOG_ERRORS_ONLY flag could be added to PAM which services running
regularly and not representing a security risk such as cron could add when PAM
is called.

The quiet option to pam_unix is not as useful because when added to system-auth
it would silence all session calls even from daemons as ssh where the logging is
useful and doesn't clutter the log file.
Comment 5 IBM Bug Proxy 2005-11-03 14:36:23 EST
---- Additional Comments From corryk@us.ibm.com(prefers email via kevcorry@us.ibm.com)  2005-11-03 14:34 EDT -------
Reposting earlier comment from Emily which got missed by the mirroring tools:

--- Additional Comment #2 From Emily J. Ratliff  2005-10-28 09:34 EDT ----

According to /usr/share/doc/pam-0.79/txts/README.pam_unix and the
pam_unix_sess.c source, the only point to having pam_unix in the session stack
is to provide this level of logging. This logging can be suppressed by
commenting out the line in /etc/pam.d/crond that invokes the system-auth session
stacking and uncommenting the session pam_limits line, since the only pam
modules invoked in the system-auth session stack are pam_unix and pam_limits. 

So on a FC4 system, the /etc/pam.d/crond file would contain
#
# The PAM configuration file for the cron daemon
#
#
auth       sufficient pam_rootok.so
auth       required   pam_stack.so service=system-auth
auth       required   pam_env.so
account    required   pam_stack.so service=system-auth
account    required   pam_access.so
#session    required   pam_stack.so service=system-auth
session    required   pam_loginuid.so
# To enable PAM user limits for cron jobs,
# configure /etc/security/limits.conf and
# uncomment this line:
session  required   pam_limits.so
# 
Comment 6 Tomas Mraz 2005-11-03 14:53:56 EST
Yes, this makes sense. It would be probably the easiest way how to resolve this
bug and it shouldn't break anything.
Comment 7 Tomas Mraz 2007-02-06 10:13:41 EST
This was fixed a long ago.

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