2053750 – cron should not be using pam_systemd

This bug has been migrated to another issue tracking site. It has been closed here and may no longer be being monitored.

If you would like to get updates for this issue, or to participate in it, you may do so at Red Hat Issue Tracker .

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 2053750 - cron should not be using pam_systemd

Summary: cron should not be using pam_systemd

Keywords:
Status:	CLOSED MIGRATED
Alias:	None
Product:	Red Hat Enterprise Linux 8
Classification:	Red Hat
Component:	cronie
Sub Component:
Version:	8.5
Hardware:	x86_64
OS:	Linux
Priority:	unspecified
Severity:	high
Target Milestone:	rc
Target Release:	---
Assignee:	Ondřej Pohořelský
QA Contact:	RHEL CS Apps Subsystem QE
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:	2112001
TreeView+	depends on / blocked

Reported:	2022-02-11 22:21 UTC by Brian J. Murrell
Modified:	2023-09-20 12:42 UTC (History)
CC List:	4 users (show)
Fixed In Version:
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Clones:	2112001 (view as bug list)
Environment:
Last Closed:	2023-09-20 12:42:06 UTC
Type:	Bug
Target Upstream Version:
Embargoed:
Dependent Products:
Flags:	pm-rhel: mirror+

Attachments	(Terms of Use)
Testing RPM (117.25 KB, application/x-rpm) 2022-03-08 13:32 UTC, Jan Staněk	no flags	Details
View All

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Issue Tracker	RHEL-5374	0	None	Migrated	None	2023-09-20 12:42:02 UTC
Red Hat Issue Tracker	RHELPLAN-112071	0	None	None	None	2022-02-11 22:22:37 UTC

Description Brian J. Murrell 2022-02-11 22:21:55 UTC

Description of problem:
Every user cron job is spamming the logs with systemd session messages.

Version-Release number of selected component (if applicable):
cronie-1.5.2-4.el8.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Create a cron job for a user at some reasonably high frequency, say every 5 minutes
2. Wait for cron job to fire

Actual results:
For every job, messages file is spammed with the like of:

04:06:01 systemd Created slice User Slice of UID 1001.
04:06:01 systemd Starting User runtime directory /run/user/1001...
04:06:01 systemd Started User runtime directory /run/user/1001.
04:06:01 systemd Starting User Manager for UID 1001...
04:06:02 systemd Starting D-Bus User Message Bus Socket.
04:06:02 systemd Started Mark boot as successful after the user session has run 2 minutes.
04:06:02 systemd Reached target Timers.
04:06:02 systemd Reached target Paths.
04:06:02 systemd Listening on D-Bus User Message Bus Socket.
04:06:02 systemd Reached target Sockets.
04:06:02 systemd Reached target Basic System.
04:06:02 systemd Started User Manager for UID 1001.
04:06:02 systemd Reached target Default.
04:06:02 systemd Startup finished in 65ms.
04:06:02 systemd pam_unix(systemd-user:session): session opened for user brian by (uid=0)
04:06:06 systemd session-2180.scope: Succeeded.
04:06:13 systemd session-2177.scope: Succeeded.
04:06:16 systemd Stopping User Manager for UID 1001...
04:06:16 systemd Stopped target Default.
04:06:16 systemd Stopped target Basic System.
04:06:16 systemd Stopped target Timers.
04:06:16 systemd Stopped Mark boot as successful after the user session has run 2 minutes.
04:06:16 systemd Stopped target Paths.
04:06:16 systemd Stopped target Sockets.
04:06:16 systemd Closed D-Bus User Message Bus Socket.
04:06:16 systemd Reached target Shutdown.
04:06:16 systemd Starting Exit the Session...
04:06:16 systemd user: Succeeded.
04:06:16 systemd Stopped User Manager for UID 1001.
04:06:16 systemd Stopping User runtime directory /run/user/1001...
04:06:16 systemd run-user-1001.mount: Succeeded.
04:06:16 systemd user-runtime-dir: Succeeded.
04:06:16 systemd Stopped User runtime directory /run/user/1001.
04:06:16 systemd Removed slice User Slice of UID 1001.
04:06:16 systemd pam_unix(systemd-user:session): session closed for user brian

Expected results:
No landslide of systemd spam for each and every cron job run

Additional info:
Talking to the systemd maintainers, their assertion is that cron should not be invoking pam_systemd.

Indeed, changing /etc/pam.d/crond to:

#
# The PAM configuration file for the cron daemon
#
#
# Although no PAM authentication is called, auth modules
# are used for credential setting
auth include password-auth
account required pam_access.so
account include password-auth
#session required pam_loginuid.so
# don't use password-auth's session -- it adds too much spam to logs
#session include password-auth
# copied from /etc/pam.d/password-auth
session optional pam_keyinit.so revoke
session required pam_limits.so
# but comment out to see if this stops all of the systemd noise
#-session optional pam_systemd.so
session optional pam_oddjob_mkhomedir.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_sss.so

does indeed squelch the noise.

Comment 1 Jan Staněk 2022-03-07 13:42:22 UTC

This may already been fixed via bug#2005526. Please try to update to cronie-1.5.2-6.el8 or newer and see if the problem still persist.

Comment 2 Brian J. Murrell 2022-03-07 13:54:18 UTC

The version current in the latest EL8 (8.5) is still cronie-1.5.2-4.el8.x86_64.

How would I update to cronie-1.5.2-6.el8 or newer on an EL8.5 machine?

Comment 3 Jan Staněk 2022-03-08 13:32:39 UTC

Created attachment 1864600 [details]
Testing RPM

Sorry, my mistake. The fix is yet to head out in the 8.6 release. I'm attaching a testing RPM to this bug to help you verify if the fix is indeed contained in the upcoming update.

Let me know if it works for you, and if so, if you want this to be backported into the 8.5 z-stream or if you are content with it being delivered in 8.6. Thanks!

Comment 4 Welterlen Benoit 2022-07-28 15:09:07 UTC

Hello,

I was investigate this issue, but with RHEL9, because in addition to the verbosity (and useless systemd session), it creates an AUTH error:


type=CRED_ACQ msg=audit(07/18/22 14:34:01.335:375) : pid=4429 uid=root auid=unset ses=unset subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_env,pam_unix acct=test exe=/usr/sbin/crond hostname=? addr=? terminal=cron res=success' 
type=CRED_ACQ msg=audit(07/18/22 14:34:01.478:379) : pid=4432 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg='op=PAM:setcred grantors=? acct=test exe=/usr/lib/systemd/systemd hostname=? addr=? terminal=? res=failed'  

Thus I tried the attached fixed rpm (on RHEL 8) and the messages are still there.
What does the fix consist of ?

I workaround that with this pam system-auth config:

---
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authselect is run.
auth        required      pam_env.so
auth        sufficient    pam_unix.so try_first_pass nullok
auth        required      pam_deny.so

account     required      pam_unix.so

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password    sufficient    pam_unix.so try_first_pass use_authtok nullok sha512 shadow
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
-session     optional      pam_systemd.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
---

Will also open on RHEL9.

Thank you !

Comment 7 RHEL Program Management 2023-09-20 12:40:18 UTC

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

Comment 8 RHEL Program Management 2023-09-20 12:42:06 UTC

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.

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