On some 3rd-party CIS/auditing reports, the recommendation is to remove /etc/cron.deny when there's no user to actively deny.
Quoting Tanium Comply:
"If cron is installed in the system, configure /etc/cron.allow to allow specific users to use these services. If /etc/cron.allow does not exist, then /etc/cron.deny is checked. Any user not specifically defined in those files is allowed to use cron. By removing the file, only users in /etc/cron.allow are allowed to use cron."
Would it make sense to add a parameter to delete the /etc/cron.deny file (when manage_users_deny=>false) to pacify 3rd-party vendors like this?
Could cron::manage_users_deny boolean be changed to an enum to accept ['true', 'false', 'absent'] or perhaps enforce the state of absent when manage_users_deny is false?
I realize I could set manage_users_deny=> false and then file{'/etc/cron.deny': state=>absent} but that kindof obfuscates the management of the file.
bschonec
commented
2 weeks ago
On some 3rd-party CIS/auditing reports, the recommendation is to remove /etc/cron.deny when there's no user to actively deny.
Quoting Tanium Comply:
"If cron is installed in the system, configure /etc/cron.allow to allow specific users to use these services. If /etc/cron.allow does not exist, then /etc/cron.deny is checked. Any user not specifically defined in those files is allowed to use cron. By removing the file, only users in /etc/cron.allow are allowed to use cron."
Would it make sense to add a parameter to delete the /etc/cron.deny file (when manage_users_deny=>false) to pacify 3rd-party vendors like this?
Could cron::manage_users_deny boolean be changed to an enum to accept ['true', 'false', 'absent'] or perhaps enforce the state of absent when manage_users_deny is false?
I realize I could set manage_users_deny=> false and then file{'/etc/cron.deny': state=>absent} but that kindof obfuscates the management of the file.