Bug 217512 - PAM connection refused with vanilla kernel, cron jobs not executed
Summary: PAM connection refused with vanilla kernel, cron jobs not executed
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: vixie-cron
Version: 6
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
Assignee: Marcela Mašláňová
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-11-28 11:59 UTC by Jan "Yenya" Kasprzak
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-11-29 15:26:00 UTC
Type: ---
Embargoed:


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

Description Jan "Yenya" Kasprzak 2006-11-28 11:59:18 UTC
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 11:59:18 UTC
Created attachment 142278 [details]
2.6.19-rc5 kernel config

Comment 2 Marcela Mašláňová 2006-11-29 13:13:03 UTC
Could you send me whole strace? Thanks.

Comment 3 Jan "Yenya" Kasprzak 2006-11-29 13:27:52 UTC
Created attachment 142379 [details]
Strace of crond

Comment 4 Marcela Mašláňová 2006-11-29 13:46:32 UTC
Have you this user (www) int /etc/shadow?

Comment 5 Jan "Yenya" Kasprzak 2006-11-29 15:16:50 UTC
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 15:26:00 UTC
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.