Failed to open PAM security session
If one day you notice that your super-duper script doesn’t work when executed from cron and crond itself is whining about:
CRON (username) ERROR: failed to open PAM security session: Success CRON (username) ERROR: cannot set security context
Then the most obvious step from here is to take a look at /etc/pam.d/crond and /var/log/secure (if you’re running Redhat based Linux distro):
# # The PAM configuration file for the cron daemon # # auth sufficient pam_rootok.so auth required pam_env.so auth include system-auth account required pam_access.so account include system-auth session required pam_loginuid.so session include system-auth
In case if /var/log/secure has similar lines check your /etc/security/access.conf and make sure that cron is allowed for everyone or at least for the user experiencing the problem:
pam_access(crond:account): access denied for user `username’ from `cron’
Otherwise, a word “session” should give you a hint on a possible issue with system-auth section. Lets check it:
cat /etc/pam.d/system-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth required pam_deny.so account required pam_unix.so account sufficient pam_succeed_if.so uid < 500 quiet account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok 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 required pam_unix.so
The most critical module here is pam_unix.so which retrieves account information from /etc/passwd and /etc/shadow. Check them for the consistency because in my case /etc/shadow was a culprit missing a record for a username. Once it was fixed the errors had stopped popping up.
on February 8, 2012 at 7:19 pm
· Permalink
[…] most of the fixed they mentioned is to check the /etc/pam.d/crond and /var/log/secure. (click here for an […]
on May 3, 2012 at 1:11 am
· Permalink
Thanks for the article it helps me to save me a little headache :)
After a massive implementation of LDAP authentication in my company some machines begin to exhibit this error message for every local account. At the end the problem was on access.conf
Thanks again my friend.
on May 3, 2012 at 10:10 am
· Permalink
Hi Leonardo,
Thank you very much for your kind response.
I’m endlessly happy to hear that my humble post has helped in your troubleshooting and saved you some time that now you could spend on something more fascinating than fixing LDAP authentication issues. Frankly speaking, it could be boring and pesky at times. ;-)
Have fun!
Cheers.
on May 15, 2012 at 12:58 pm
· Permalink
[…] your user account to the list before commenting it out. Additionally, according to this link: http://www.flagword.net/2009/09/fail…urity-session/ you may want to double check the /etc/pam.d/system-auth configuration very carefully (as well as […]
on January 5, 2016 at 6:03 pm
· Permalink
Hello,
It helped.
I reset the user passwd and everything went back to normal.
Thank you
on February 17, 2016 at 3:15 pm
· Permalink
You might find this problem inside a Linux container (lxc). I’m not sure what the root cause is, but the it starts with `pam_loginuid.so` module. Discussions on the Linux-container mailing list in 2013 suggest one remedy: replace pam_loginuid.so with a (soft)link to `pam_permit.so`. See `/lib64/security`. This solution is fine if your filesystem is not shared with other linux containers. Otherwise, comment-out all instances of `pam_loginuid.so` from pam.d modules.
on February 17, 2016 at 3:24 pm
· Permalink
Thanks for a great addition. I personally didn’t know about that as I have zero experience with lxc.