Bug 2059479

Summary: cronie upgrade or reinstallation recreates the /etc/cron.deny file [rhel-7.9.z]
Product: Red Hat Enterprise Linux 7 Reporter: Renaud Métrich <rmetrich>
Component: cronieAssignee: Ondřej Pohořelský <opohorel>
Status: CLOSED ERRATA QA Contact: Jan Houska <jhouska>
Severity: low Docs Contact:
Priority: low    
Version: 7.9CC: abetkike, jhouska, kpfleming, opohorel, sbalasub
Target Milestone: rcKeywords: Triaged
Target Release: ---Flags: pm-rhel: mirror+
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-04-25 13:26:39 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Renaud Métrich 2022-03-01 07:02:34 UTC
This bug was initially created as a copy of Bug #2059477

I am copying this bug because: 

Applies to RHEL7 as well and breaks CIS compliance

Description of problem:

When reinstalling or upgrading cronie package, the /etc/cron.deny file is re-created automatically (to an empty file).
This is an issue when hardening the system for CIS because the CIS rule requires that /etc/cron.deny be removed.

See below extracted from scap-security-guide sources linux_os/guide/services/cron_and_at/restrict_at_cron_users/group.yml:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
title: 'Restrict at and cron to Authorized Users if Necessary'

description: |-
    The <tt>/etc/cron.allow</tt> and <tt>/etc/at.allow</tt> files contain lists of
    users who are allowed to use <tt>cron</tt> and at to delay execution of
    processes. If these files exist and if the corresponding files
    <tt>/etc/cron.deny</tt> and <tt>/etc/at.deny</tt> do not exist, then only users
    listed in the relevant allow files can run the crontab and <tt>at</tt> commands
    to submit jobs to be run at scheduled intervals. On many systems, only the 
    system administrator needs the ability to schedule jobs. Note that even if a
    given user is not listed in <tt>cron.allow</tt>, cron jobs can still be run as
    that user. The <tt>cron.allow</tt> file controls only administrative access
    to the crontab command for scheduling and modifying cron jobs.
    <br />
    <br />
    To restrict <tt>at</tt> and <tt>cron</tt> to only authorized users:
    <ul>
    <li>Remove the <tt>cron.deny</tt> file:<pre>$ sudo rm /etc/cron.deny</pre></li>
    <li>Edit <tt>/etc/cron.allow</tt>, adding one line for each user allowed to use 
    the crontab command to create cron jobs.</li>
    <li>Remove the <tt>at.deny</tt> file:<pre>$ sudo rm /etc/at.deny</pre></li>
    <li>Edit <tt>/etc/at.allow</tt>, adding one line for each user allowed to use 
    the at command to create at jobs.</li>
    </ul>
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------


Version-Release number of selected component (if applicable):

All cronie releases

How reproducible:

Always

Steps to Reproduce:
1. Delete /etc/cron.deny
2. Reinstall the package

Actual results:

Empty file /etc/cron.deny re-created

Expected results:

No file created

Comment 19 errata-xmlrpc 2023-04-25 13:26:39 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (cronie bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:1989