9

Ubuntu 14.04

I don't understand the behaviour I'm seeing with setting up crontab for a service (no login) account (named curator).

When I'm logged in as root, this is what I get:

# crontab -u curator -l
The user curator cannot use this program (crontab)

But, when I switch to the user's account, it works fine:

# su -s /bin/bash curator
curator@host$ crontab -l
no crontab for curator

There is an empty /etc/cron.allow file and no /etc/cron.deny file on the system. According to man crontab:

If the /etc/cron.allow file exists, then you must be listed (one user per line) therein in order to be allowed to use this command. If the /etc/cron.allow file does not exist but the /etc/cron.deny file does exist, then you must not be listed in the /etc/cron.deny file in order to use this command.

I understand the error when I'm running the first command, but why does it allow me to run crontab when I explicitly switch to the user's account?

Adding the user to /etc/cron.allow makes both commands work fine.

  • 1
    It just says that there is no crontab. What will happen if you try to create one via crontab -e (as user curator)? – Fiximan Jul 27 '16 at 16:02
  • 1
    Cannot reproduce this issue on the vagrant trusty64 image; with an empty cron.allow file, both the root crontab -u vagrant -l and crontab -l as vagrant result in a are not allowed to use this program message (which is different from the message you quote). – thrig Jul 27 '16 at 16:45
11

I checked the crontab sources and found that if the user cannot open /etc/cron.allow (for instance after chmod 0 /etc/cron.allow), crontab thinks the user is allowed to use it (as if cron.allow did not exist).

But root can read any file, so crontab checking code works as expected. So I recommend you to check first permissions on /etc/cron.allow, and maybe SELinux/AppArmor audit logs.

  • This seems to be it - I have verified that chmod -r /etc/cron.allow indeed causes the described behavior on my Ubuntu 14.04 system – steeldriver Jul 27 '16 at 17:57
  • Spot on! My /etc/cron.allow permissions were 600, after changing it to 644 both root and curator saw the not allowed to use this program (crontab) message. Then, after adding curator to /etc/cron.allow both could use curator's crontab. – Adam Michalik Jul 28 '16 at 7:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.