cron

You are not allowed to access to (crontab) because of pam configuration.

/ Christopher Paquin / 1 Comment

PD Donut Guy with ShadowHey look a real live Linux post.

Sure enough, and right as rain I am back with something that is not about networking (yeah!) and not about Solaris (boo!).

This is a short story about how we had a user who was a member of our database team who was attempting to make modifications to the oracle user’s crontab. They kept running into the error below.

Authentication token expired
You (oracle) are not allowed to access to (crontab) because of pam configuration.

Remembering that the oracle account is a special account without a password, or the ability to login, I figured that it had something to do with the fact the lack or password or something related.

I used the chage command to determine that while the password was not expired, rather that the account was considered inactive. Probably due to the fact that we locked down login permissions for service users on this box, but did not take into account that this user needed to login from time to time to keep the account from becoming inactive.

# chage -l oracle
Last password change                                    : Mar 25, 2013
Password expires                                        : Apr 22, 2013
Password inactive                                       : May 06, 2013
Account expires                                         : never
Minimum number of days between password change          : 7
Maximum number of days between password change          : 28
Number of days of warning before password expires       : 7

Now whats funny about this issue is that its pretty much a time bomb waiting to go off. You lock down logins for service accounts and forget to modify the inactive or expiration dates, and some day in the near future your users cron jobs will stop running, which possibly could cause all hell to break loose depending on whats running out of cron.

The fix is as follows.

# chage -I -1 -m 0 -M 99999 -E -1 oracle

Then use chage again to check out the sexy new settings

# chage -l oracle
Last password change                                    : Mar 25, 2013
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7

Related articles

HomeLab: Simple SSH Setup on a Cisco Router
HomeLab: Cisco 2621 Router Password Recovery/Factory Reset
chkcrontab 1.6
How to Use Cron to Automate Tasks on a VPS

RHEL6 – Simple Crontab Access Control

/ Christopher Paquin / 3 Comments

12161376021593473697lemmling_Cartoon_goat.svg.medWhile I am in the process of documenting each and every possible method of blocking or allowing a local user or remote user access from a service, I figured that I might as well drop a small little post out there on the subject of cron.allow and cron.deny.  First off you should know that allowing and blocking access to cron is very, very easy as you only need to know two files and there is not a special

Basically you are working with two files, the /etc/cron.allow and /etc/cron.deny.

Users are allowed to run cronjobs if:

  • if the user’s name appears in /etc/cron.d/cron.allow.
  • if  /etc/cron/cron.allow does not exist and the user’s name is not in /etc/cron/cron.deny.

Users are blocked from running cronjobs if:

  • /etc/cron/cron.allow exists and the user’s name is not in it.
  • /etc/cron/cron.allow does not exist and user’s name is in /etc/cron/cron.deny.

Note that the rules for allow and deny apply to root only if the allow/deny files exist.

Below is what a blocked user will see if they try to create a crontab entry

$ crontab -l
You (fatmin( are not allowed to use this program (crontab)
See crontab(1) for more information