Bug 217512 - PAM connection refused with vanilla kernel, cron jobs not executed
PAM connection refused with vanilla kernel, cron jobs not executed
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: vixie-cron (Show other bugs)
6
All Linux
medium Severity low
: ---
: ---
Assigned To: Marcela Mašláňová
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-28 06:59 EST by Jan "Yenya" Kasprzak
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-29 10:26:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
2.6.19-rc5 kernel config (31.56 KB, text/plain)
2006-11-28 06:59 EST, Jan "Yenya" Kasprzak
no flags Details
Strace of crond (42.82 KB, text/plain)
2006-11-29 08:27 EST, Jan "Yenya" Kasprzak
no flags Details

  None (edit)
Description Jan "Yenya" Kasprzak 2006-11-28 06:59:18 EST
Description of problem:
I use freshly installed FC6 with vanilla kernel (I will attach the kernel
config), and on the server crond cannot run the cron jobs, with the following
messages in /var/log/cron:

Nov 26 04:03:01 server crond[3123]: Authentication service cannot retrieve
authentication info
Nov 26 04:03:01 server crond[3123]: CRON (www) ERROR: failed to open PAM
security session: Connection refused
Nov 26 04:03:01 server crond[3123]: CRON (www) ERROR: cannot set security context

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

vixie-cron-4.1-64.x86_64, but tested also FC5 one:
vixie-cron-4.1-58.fc5.x86_64

How reproducible:
100%

Steps to Reproduce:
1. install FC6 system with the attached kernel config
2. add a cron job to the system crontab for non-root user (www in my case)
3. wait for the cron job to be scheduled
  
Actual results:
the above messages in the system log, the job is not executed.


Expected results:
the job should be executed; vixie-cron should work even on vanilla kernels.

Additional info:
I have straced crond, and before printing the above messages to the system log,
it unsuccessfully tries to send some data over AF_NETLINK socket, getting
ECONNREFUSED. I can attach the strace output on request.

Rebuilding the vixie-cron RPM without PAM support (--define 'WITH_PAM 0')
"fixes" the problem.

I have looked into the default PAM configuration - it seems that in
/etc/pam.d/system-auth there is the following exception for crond, just before
the pam_unix.so is called:

session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet
use_uid

adding a similar exception above the pam_unix.so call also to the "account"
section fixes the problem. Temporarily commenting out the pam_unix.so call in
the "account" section out also "fixes" the problem.

I do not fully understand the problem, but I think adding the above exception to
the "account" section of /etc/pam.d/system-auth should be the apporopriate solution.

I have tested this under 2.6.18.1 and 2.6.19-rc5 (for which the config is attached).

I am giving this low priority because of the unsupported kernel configuration.
Comment 1 Jan "Yenya" Kasprzak 2006-11-28 06:59:18 EST
Created attachment 142278 [details]
2.6.19-rc5 kernel config
Comment 2 Marcela Mašláňová 2006-11-29 08:13:03 EST
Could you send me whole strace? Thanks.
Comment 3 Jan "Yenya" Kasprzak 2006-11-29 08:27:52 EST
Created attachment 142379 [details]
Strace of crond
Comment 4 Marcela Mašláňová 2006-11-29 08:46:32 EST
Have you this user (www) int /etc/shadow?
Comment 5 Jan "Yenya" Kasprzak 2006-11-29 10:16:50 EST
I dont have it (good spotting!). After adding it (using pwconv) it works.
However, it seems that other utilities (except crond) work even when the user is
not in shadow (su, for example). I don't think having the user in shadow is
required for things like crond.
Comment 6 Tomas Mraz 2006-11-29 10:26:00 EST
It doesn't have to be in shadow but then its password part of the entry in
/etc/passwd must not be x or begin with ##.

su does work because when su-ing from root the account check is skipped.

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