Description of problem: Log file creation permissions are hardcoded to 644 (-rw-r--r--) here. Comments mention a default, but there is no override available in the config file. https://github.com/rpm-software-management/dnf/blob/master/dnf/logging.py def _create_filehandler(logfile, log_size, log_rotate): ... # By default, make logfiles readable by the user (so the reporting ABRT # user can attach root logfiles). os.chmod(logfile, 0o644) This clashes with server hardening and compliance. For example, CIS benchmarks include this rule, which doesn't like any world permissions. 4.2.3 Ensure permissions on all logfiles are configured (Scored) Version-Release number of selected component (if applicable): All How reproducible: Delete logs, run a dnf command, check new logs. Steps to Reproduce: 1. rm /var/log/dnf* 2. dnf repolist 3. ls -l /var/log/dnf* Actual results: Files are recreated with permissions 644. Expected results: Files are created with user-specified permissions or a default of 644. Additional info: This can be fixed with additional variable in the config file, then passing the value through to _create_filehandler. Config file addition could look like this. /etc/dnf/dnf.conf log_perm=640 This approach would require more additions: * docs at https://dnf.readthedocs.io/ and dnf.conf man page * test suite
I made a patch to remove the hardcoded permissions. By default, the permissions will still be 644 due to the default umask for the root user being 022. PR: https://github.com/rpm-software-management/dnf/pull/1714 Tests: https://github.com/rpm-software-management/ci-dnf-stack/pull/940 However, we are hesitant to introduce a new config option just for this. Is there a reason for it or is it sufficient that the permissions are no longer hardcoded?
Many thanks for this. It's really only one reason - a customer was trying to remove world write, for compliance reasons, and tripping over this. I reckon this will do the trick, because I bet they hardened the umask to 0027. Another way of doing this is to not even try to handle logging, and send logs to syslog. Let rsyslog handle logging. I haven't researched this at all, and nobody's asked me about it. Is syslog an option?
(In reply to Nick Hardiman from comment #2) > Many thanks for this. > It's really only one reason - a customer was trying to remove world write, > for compliance reasons, and tripping over this. I reckon this will do the > trick, because I bet they hardened the umask to 0027. All right then, thanks for the confirmation. > Another way of doing this is to not even try to handle logging, and send > logs to syslog. Let rsyslog handle logging. I haven't researched this at > all, and nobody's asked me about it. > Is syslog an option? We have considered syslog for the upcoming version of dnf, but the main problem is that dnf also runs in environments where systemd is not available, such as containers, so we still need a custom implementation of logging. However, I'm not sure what the exact plans are.
Additional PR is needed to also preserve the permissions during log rotation: https://github.com/rpm-software-management/dnf/pull/1736
FEDORA-2021-447fb19490 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-447fb19490
FEDORA-2021-447fb19490 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-447fb19490` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-447fb19490 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-447fb19490 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.