It wasn't just yum; None of my cron jobs were running after I changed system-auth

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I was asking about why the yum cron job does not run, and kept working until I realized that none of the cron jobs were running except when a reboot triggered anacron cleanup.

I think I finally understand it, and was hoping to use you as a sounding board to see if my guess at the solution is viable. I also need an opinion if you think this is a bug in the system-config-authentication package that needs to be corrected.


My pam stack was modified to allow LDAP authentication and pam_mount of a network share. I made the changes to /etc/pam.d/system-auth first with system-config-authentication, and then manually added the part for pam_mount. I just found out that that the changes make cron fail to start because cron is now "pam aware." I think, anyway.

I have been wrestling so much with the authentication that I did not notice the side effect on cron. When I su to root, it works, but there's always a message to /var/log/secure because root is not found in the LDAP server. It workes on the second try, and so I figured all was well. But, it works only after failing to authenticate against the LDAP server, and it falls back to local authentication. "su" goes through OK, but I guess the cron-pam thing is more fragile.

Here's the indication from /var/log/secure, every time when cron tries to run

Sep 1 18:01:01 pols11 crond[18092]: pam_mount: error trying to retrieve authtok from auth code Sep 1 19:01:01 pols11 crond[18107]: pam_mount: error trying to retrieve authtok from auth code Sep 1 20:01:01 pols11 crond[18122]: pam_mount: error trying to retrieve authtok from auth code Sep 1 21:01:01 pols11 crond[18137]: pam_mount: error trying to retrieve authtok from auth code


Here's my modified system-auth. It has all this special mustard in there because 1) authenticate against a Novell LDAP server, 2) pam_mount shares for users found there, and 3) create home directories for users on the local machine who authenticate but do not have home directories.

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
account    sufficient     /lib/security/$ISA/pam_ldap.so
auth        required       /lib/security/$ISA/pam_mount.so
auth        required      /lib/security/$ISA/pam_env.so
auth        sufficient    /lib/security/$ISA/pam_ldap.so use_first_pass

auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok use_first_pass

auth        required      /lib/security/$ISA/pam_deny.so

account     required      /lib/security/$ISA/pam_unix.so broken_shadow
account     sufficient    /lib/security/$ISA/pam_localuser.so
account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet account [default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_ldap.so
account     required      /lib/security/$ISA/pam_permit.so

password    requisite     /lib/security/$ISA/pam_cracklib.so retry=3
password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow
password    sufficient    /lib/security/$ISA/pam_ldap.so use_authtok
password    required      /lib/security/$ISA/pam_deny.so

session required /lib/security/$ISA/pam_mkhomedir.so skel=/etc/skel umask=0002
session    optional       /lib/security/$ISA/pam_mount.so
session     required      /lib/security/$ISA/pam_limits.so
session     required      /lib/security/$ISA/pam_unix.so
session     optional      /lib/security/$ISA/pam_ldap.so



What do you think about fixing this by taking the crond pam file and cutting out the parts it grabs from system-auth, and instead of those parts, cram in the equivalent parts from the system-auth that existed before I did LDAP. See what I mean?

Replace this old crond file:
# /etc/pam.d/crond
#
# 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
#


Can it do any damage to put in the original system-auth lines? Am I insecure?

# proposed /etc/pam.d/crond
#
# The PAM configuration file for the cron daemon
#
#
auth       sufficient pam_rootok.so
#paste 3 auth lines from original system-auth
auth        required      /lib/security/$ISA/pam_env.so
auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok
auth        required      /lib/security/$ISA/pam_deny.so

auth       required   pam_env.so

#paste 3 account lines from original system auth
account     required      /lib/security/$ISA/pam_unix.so
account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet
account     required      /lib/security/$ISA/pam_permit.so

account    required   pam_access.so
#paste 2 session lines from original system auth
session     required      /lib/security/$ISA/pam_limits.so
session     required      /lib/security/$ISA/pam_unix.so


--------------------------------

I'm testing that now and it SEEMS to be working, but I have no idea what secondary effects it might be causing. What dangers lurk?



--
Paul E. Johnson                       email: pauljohn@xxxxxx
Dept. of Political Science            http://lark.cc.ku.edu/~pauljohn
1541 Lilac Lane, Rm 504
University of Kansas                  Office: (785) 864-9086
Lawrence, Kansas 66044-3177           FAX: (785) 864-5700

--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list

[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]