Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1479064 - crontab(1) generates pam error "PAM pam_end: NULL pam handle passed"
crontab(1) generates pam error "PAM pam_end: NULL pam handle passed"
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: cronie (Show other bugs)
7.4
x86_64 Unspecified
high Severity medium
: rc
: ---
Assigned To: Tomas Mraz
Vaclav Danek
:
Depends On:
Blocks: 1420851
  Show dependency treegraph
 
Reported: 2017-08-07 17:33 EDT by Michael Bauer
Modified: 2018-05-22 00:36 EDT (History)
11 users (show)

See Also:
Fixed In Version: cronie-1.4.11-18.el7
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-04-10 07:55:08 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Do not call pam_end with NULL pamh (696 bytes, patch)
2017-09-15 03:40 EDT, Tomas Mraz
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0738 None None None 2018-04-10 07:55 EDT

  None (edit)
Description Michael Bauer 2017-08-07 17:33:02 EDT
Description of problem: cron generates pam error: "PAM pam_end: NULL pam handle passed"


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

cronie-1.4.11-17.el7.x86_64
pam-1.1.8-18.el7.x86_64
sudo-1.8.19p2-10.el7.x86_64


How reproducible:

Every time.


Steps to Reproduce:
1. Upgrade to RHEL 7.4
2. Cron/pam/sudo throws new errors.


Actual results:

/var/log/cron contains new entries, twice an hour:

Aug  7 09:26:49 lab116x crontab[24982]: PAM pam_end: NULL pam handle passed


Expected results:

No logged entries complaining about NULL pam handles.



Additional info:

So far as I can tell, there are no cron jobs on any of these machines that run every 30 minutes.

I see pointers in earlier versions of this error, notably on Arch and Debian bugfixes, that blame this on a problem in sudo, which is why I provided the sudo version.  See:

https://bbs.archlinux.org/viewtopic.php?id=129211
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646478
Comment 2 Tomas Mraz 2017-08-08 03:05:05 EDT
Please report the issue through regular Red Hat support channels to help appropriately prioritizing the issue.

https://www.redhat.com/support
Comment 3 Tomas Mraz 2017-08-08 03:08:01 EDT
Also we will need more information to investigate. I am unable to reproduce the issue here.
Comment 4 Michael Bauer 2017-08-08 13:02:12 EDT
I have also found at least one of our RHEL 7 machines that took the upgrade and has not started generating errors.  I will investigate further and see if I can find the difference.
Comment 5 Michael Bauer 2017-08-08 13:13:07 EDT
The machine that was generating no errors had nothing in /var/spool/cron.  All the machines that do generate errors have at least a root crontab separate from the /etc/cron.[timespan] directories.  The vast majority of our RHEL 7 systems have at least a root crontab.

When I edited one machine's crontab to delete every entry, but leave the empty file, I got more of the errors.  I also got more errors when I outright deleted the machine's root crontab with 'crontab -r'.

I have taken two machines that were generating errors, and changed them: one machine now has nothing at all in /var/spool/cron; the other has an empty root crontab in /var/spool/cron.  I will see if either of them throws the errors over the next hour.
Comment 6 Michael Bauer 2017-08-08 13:22:38 EDT
Further investigation: non-root crontabs do not trigger the error, nor does running crontab(1) as an ordinary user.  Running crontab(1) as root to operate on an ordinary user's crontab does trigger the error.
Comment 7 Michael Bauer 2017-08-08 14:49:09 EDT
It's been an hour, and both altered machines have produced no new errors.  I'm putting their respective crontabs back and will see if the error recurs.

Unless something extremely weird is going on, it is nigh unto certain that the 30 minute intervals are puppet using crontab as root to inspect the cron jobs it controls.

So, ultimately, the proper description of the bug:

1) Run crontab(1) as root for any purpose.
2) Get a log entry as pasted above.

This is new behavior in RHEL 7.4.
Comment 8 Tomas Mraz 2017-08-09 03:22:30 EDT
OK, this makes sense. So the severity is low because it is not logged from crond itself but only if crontab is called as root. Nevertheless it is a regression.

So thanks for the investigation, but please still report the issue via the regular support channels if you can so we can properly prioritize the fix.
Comment 9 Michael Bauer 2017-08-09 13:40:55 EDT
Opened case 1908249, https://access.redhat.com/support/cases/#/case/01908249.
Comment 19 Tomas Mraz 2017-09-15 03:40 EDT
Created attachment 1326358 [details]
Do not call pam_end with NULL pamh

This patch is part of an upstream commit that contains more changes not relevant to RHEL-7 cronie.
Comment 29 errata-xmlrpc 2018-04-10 07:55:08 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0738

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