10

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.

22
  • Did you tried to log in as cron and execute the commands? May 21, 2013 at 9:40
  • @l0b0, what about the permissions of the crontab file itself, inside the crontabs folder, i.e. /var/spool/cron/crontabs/username?
    – Alaa Ali
    May 21, 2013 at 9:56
  • 1
    Hmm. What does /var/log/auth.log say about CRON?
    – Alaa Ali
    May 21, 2013 at 10:30
  • @NotFromBrooklyn id cron -> id: cron: No such user
    – l0b0
    May 21, 2013 at 14:24
  • 1
    @ssoto How do I find out? I am a local user, if that's what you mean.
    – l0b0
    May 22, 2013 at 8:03

3 Answers 3

3

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:

session [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid

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.

2
  • I had the same line (must have got it from somewhere on the interwebs), commented it out and everything started working again.
    – Mike
    Nov 19, 2014 at 1:34
  • Correct. See also my answer on SuperUser here: superuser.com/questions/1321790/… Mar 17, 2022 at 23:33
1

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"

8
  • I should be clear, a finger print scanner should normally be "optional" not "required". Making it "required" means that things without your fingerprint can't "login". Because of a configuration error like that you could end up with a issue like this. However, normally a finger print scanner (or USB or LDAP or SMB or whatever) would not cause the issue.
    – coteyr
    May 22, 2013 at 12:40
  • I have not connected any fingerprint scanners or USB drives. Do you perhaps know somewhere I can check what the default content of /etc/pam.d/common-* would be?
    – l0b0
    May 27, 2013 at 8:12
  • sudo dpkg-reconfigure pam is the best way. However, you can use sudo dpkg -i --force-confmiss after deleting the file (CAREFUL) and it will put one back see this link: superuser.com/questions/69045/…
    – coteyr
    May 27, 2013 at 14:25
  • /usr/sbin/dpkg-reconfigure: pam is not installed. I also tried sudo dpkg-reconfigure libpam-runtime, but that didn't help.
    – l0b0
    May 27, 2013 at 15:08
  • 1
    I do not think it's a missing package. I think it's a messed up config. The error "PAM bad jump in stack" means that, for some reason, a required pam module could not authenticate. As I said this is normally caused by people messing with their pam files either knowingly or incidently and adding a required module that is not working. Some examples would be SMB authentication, LDAP authentication, hardware based authentication, etc. Keep in mind, some package may have added a file that is causing the problem. Pam is working, cause you can login, but it's also not working because cron can't
    – coteyr
    May 27, 2013 at 19:38
1

We were trying to schedule cron from a LDAP user (non machine user) and getting the same permission denied for even putting basic echo command or script in crontab, 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:

pam_sss(cron:account): Access denied for user my_username: 6 (Permission denied)

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.

[domain/my.domain.com]
....
ad_gpo_map_interactive = +cron

And then just did sudo service sssd restart and it works like a charm.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .