644 Permission needed for /etc/cron.allow, workaround?

dsideriu

11/18/23, 11:11 PM

There is an odd CRONTAB behavior difference between Ubuntu and RHEL-derived (say, Rocky 8.x) distros. And, because security I need to understand it better. I've tested this issue in Ubuntu 18.04 and 20.04, with identical behavior in both.

If I use a cron.allow file to allow specified users to use CRONTAB, that file must have 644 permissions. (Or at least, world-readable.) If I set the permission on /etc/cron.allow to 600, CRONTAB is unavailable to any non-root user.

In Rocky 8.x, CRONTAB works fine with a cron.allow file with 600 permission.

The reason I'm asking this is that my security team is more or less demanding that /etc/cron.allow be 600 permission, or at best 640. The problem is that CRONTAB is completely unavailable to allowed users (which means, only root can use CRONTAB) in Ubuntu with either of these permission levels.

Is there a way to change CRONTAB settings to use a 600 or 640 permission on cron.allow and, you know, make it actually work?
Is there any other way to whitelist users for CRONTAB other than cron.allow?
Any idea why this is so different in Ubuntu than in Rocky?

938

1 + 1

permissions

cron

dsideriu

11/21/23, 2:14 PM

@user68186 Yes, I tested the alternative of putting `cron.allow` in /etc/cron.d instead of /etc. There was no change in behavior.

Score:0

Ubuntu

dsideriu

1/17/24, 7:19 PM

The resolution we found is to change the group of the cron.allow file to the crontab group and then adding the relevant users to that group:

Ensure that the crontab group exists

grep crontab /etc/group)  # should return crontab:x:105 and possibly a list of users

Change group of the cron allow and set read permission:

sudo chgrp crontab /etc/cron.allow
sudo chmod 0640 /etc/cron.allow

Add users to the crontab group

sudo usermod -aG crontab *username*  # replace *username* with the relevant username

and repeat for all desired users

The end result is that the /etc/cron.allow file is readable by all users in the crontab group, which is necessary when cron.allow is used to restrict cron to certain users.

+ 0

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: 644 Permission needed for /etc/cron.allow, workaround?

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.