Update: This issue will not be answered conclusively; I have moved to another distro and have not observed this problem since. I was never able to fix it with the insightful answers available at the time, but your fuel efficiency may vary (YMMV).
crontab -e
and crontab -l
work just fine:
$ crontab -l | grep -v '^#'
* * * * * /usr/bin/env
* * * * * echo 'Hello from crontab'
However, I see two messages like this every minute in /var/log/syslog
:
Mon DD hh:mm:01 username CRON[PID]: Permission denied
So the crontab is being read, but somehow it can't execute anything at all (of course I verified the commands when logged in as the same user). Any idea why?
/etc/cron.allow
and /etc/cron.deny
do not exist.
crontab is set group setuid:
$ stat --format '%A %U %G' /usr/bin/crontab
-rwxr-sr-x root crontab
The crontabs directory seems to have the right permissions:
$ stat --format '%A %U %G' /var/spool/cron/crontabs
drwx-wx--T root crontab
The crontab itself is owned by me (not surprisingly, since I'm able to edit it):
$ sudo stat --format '%A %U %G' /var/spool/cron/crontabs/$USER
-rw------- username crontab
I am not a member of the crontab
group.
These lines appear in /var/log/auth.log
every minute (thanks @Alaa):
Mon DD hh:mm:01 username CRON[1752]: pam_unix(cron:session): session opened for user username by (uid=0)
Mon DD hh:mm:01 username CRON[1752]: PAM bad jump in stack
Maybe PAM is broken? pam-auth-update
(thanks @coteyr) lists all of these, and all of them are enabled:
- Unix authentication
- GNOME Keyring Daemon - Login keyring management
- eCryptfs Key/Mount Management
- ConsoleKit Session Management
- Inheritable Capabilities Management
Can any of them be safely disabled? I'm not using any encrypted filesystems.
Based on a Debian bug entry I tried running debconf-show libpam-runtime
, and I got the following error message:
debconf: DbDriver "passwords" warning: could not open /var/cache/debconf/passwords.dat: Permission denied
The contents of /etc/pam.d/cron
:
# The PAM configuration file for the cron daemon
@include common-auth
# Read environment variables from pam_env's default files, /etc/environment
# and /etc/security/pam_env.conf.
session required pam_env.so
# In addition, read system locale information
session required pam_env.so envfile=/etc/default/locale
@include common-account
@include common-session-noninteractive
# Sets up user limits, please define limits for cron tasks
# through /etc/security/limits.conf
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid
The files mentioned (/etc/environment
, pam_env.so
, /etc/default/locale
, pam_limits.so
, pam_succeed_if.so
) are all readable by my user.
On another host with Ubuntu 13.04, with the same user crontab, no /etc/cron.{allow,deny}
, same permissions as above, and not being a member of the crontab
group, it works just fine (logs the commands but not the output in /var/log/syslog
).
By changing the first crontab line:
* * * * * /usr/bin/env >/tmp/env.log 2>&1
and checking that /tmp is world writeable:
$ sudo -u nobody touch /tmp/test
$ ls /tmp/test
/tmp/test
$ ls -ld /tmp
drwxrwxrwt 15 root root 12288 May 27 10:18 /tmp
I've verified that the crontab commands are not run at all: The Permission denied
messages still show up in /var/log/syslog
, but /tmp/env.log
is not created.
Based on a random listing of /etc/pam.d
settings I found the following discrepancies:
$ grep '^[^#]' /etc/pam.d/sshd
@include common-auth
account required pam_nologin.so
@include common-account
@include common-session
session optional pam_motd.so # [1]
session optional pam_mail.so standard noenv # [1]
session required pam_limits.so
session required pam_env.so # [1]
session required pam_env.so user_readenv=1 envfile=/etc/default/locale
@include common-password
$ grep '^[^#]' /etc/pam.d/common-session
session [default=1] pam_permit.so
session requisite pam_deny.so
session required pam_permit.so
session optional pam_umask.so
session required pam_unix.so
session optional pam_ecryptfs.so unwrap
session optional pam_ck_connector.so nox11
$ grep '^[^#]' /etc/pam.d/common-account
account [success=1 new_authtok_reqd=done default=ignore] pam_unix.so
account requisite pam_deny.so
account required pam_permit.so
$ grep '^[^#]' /etc/pam.d/common-session-noninteractive
session [default=1] pam_permit.so
session requisite pam_deny.so
session required pam_permit.so
session optional pam_umask.so
session required pam_unix.so
session optional pam_ecryptfs.so unwrap
PAM packages installed:
$ dpkg --get-selections | grep --invert-match deinstall | cut --fields 1 | grep pam
libpam-cap
libpam-ck-connector
libpam-gnome-keyring
libpam-modules
libpam-modules-bin
libpam-runtime
libpam0g
python-pam
I tried reinstalling these - didn't help:
$ sudo apt-get install --reinstall $(dpkg --get-selections | grep --invert-match deinstall | cut --fields 1 | grep pam)
I can't purge and then reinstall these because of unmet dependencies.
PAM bad jump in stack
is a big clue.Your
/etc/pam.d/cron
differs from the stock version with the addition of one extra line at the end:The
success=1
bit means "if this module succeeds, skip the next rule". Only there's no next rule, as this is the last line in your PAM configuration.Your PAM configuration is out of sorts. This is common if you have used "external" authentication methods like fingerprint scanners, LDAP accounts, USB Keys or the sort. Basically cron can't work a fingerprint scanner so it can't login as you.
You need to remove the offending configuration from
/etc/pam.d/common-*
though tracking it down can be a bit difficult, specially if you didn't enable something manually (for example if a Finger print scanner setup script turned something on).I can't help much with telling you what should be in those files. A lot of things could be different depending on your setup. But disabling "required" auth methods till your left with just "Unix Authentication" may be a good first step.
You can do this by running
pam-auth-update
as root and un-checking the other boxes. Be very very careful as this can leave you with a system you can not login to if done incorrectly. Disable them one at a time, reboot for safety, and test. NEVER DISABLE "Unix Authentication"We were trying to schedule cron from a LDAP user (non machine user) and getting the same
permission denied
for even putting basicecho
command or script incrontab
, while it was working completely file from machines users (who have entries in /etc/passwd). Taking help from the detailed troubleshooting comments added by OP, we checked file/var/log/auth.log
where we found this line:A bit of Google search took me to this answer which worked for us. Adding the details here as well.
In
/etc/sssd/sssd.conf
, under our domain, we added an entry (see last line) like this.And then just did
sudo service sssd restart
and it works like a charm.