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.

Posted on September 7, 2009 at 12:38 pm by sergeyt · Permalink
In: Linux · Tagged with: ,

7 Responses

Subscribe to comments via RSS

  1. […] most of the fixed they mentioned is to check the /etc/pam.d/crond and /var/log/secure. (click here for an […]

  2. Written by Leonardo
    on May 3, 2012 at 1:11 am
    Reply · 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.

    • Written by sergeyt
      on May 3, 2012 at 10:10 am
      Reply · 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.

  3. Written by User cron not running.
    on May 15, 2012 at 12:58 pm
    Reply · 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 […]

  4. Written by toto
    on January 5, 2016 at 6:03 pm
    Reply · Permalink

    Hello,

    It helped.
    I reset the user passwd and everything went back to normal.

    Thank you

  5. Written by Otheus
    on February 17, 2016 at 3:15 pm
    Reply · 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.

    • Written by sergeyt
      on February 17, 2016 at 3:24 pm
      Reply · Permalink

      Thanks for a great addition. I personally didn’t know about that as I have zero experience with lxc.

Subscribe to comments via RSS

Leave a Reply