Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1910084 - hardcoded logfile permissions
Summary: hardcoded logfile permissions
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 33
Hardware: All
OS: Unspecified
unspecified
low
Target Milestone: ---
Assignee: Pavla Kratochvilova
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-12-22 15:28 UTC by Nick Hardiman
Modified: 2021-05-03 01:48 UTC (History)
9 users (show)

Fixed In Version: dnf-4.7.0-1.fc33
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-05-03 01:48:16 UTC
Type: Bug


Attachments (Terms of Use)

Description Nick Hardiman 2020-12-22 15:28:20 UTC
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

Comment 1 Pavla Kratochvilova 2021-01-27 15:40:29 UTC
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?

Comment 2 Nick Hardiman 2021-01-27 17:18:46 UTC
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?

Comment 3 Pavla Kratochvilova 2021-01-28 11:45:00 UTC
(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.

Comment 4 Pavla Kratochvilova 2021-03-02 09:56:01 UTC
Additional PR is needed to also preserve the permissions during log rotation: https://github.com/rpm-software-management/dnf/pull/1736

Comment 5 Fedora Update System 2021-04-19 16:12:46 UTC
FEDORA-2021-447fb19490 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-447fb19490

Comment 6 Fedora Update System 2021-04-19 18:33:39 UTC
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.

Comment 7 Fedora Update System 2021-05-03 01:48:16 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.