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

Summary:	hardcoded logfile permissions
Product:	[Fedora] Fedora	Reporter:	Nick Hardiman <nhardima>
Component:	dnf	Assignee:	Pavla Kratochvilova <pkratoch>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	33	CC:	dmach, jmracek, jrohel, mblaha, mhatina, packaging-team-maint, pkratoch, rpm-software-management, vmukhame
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	All
OS:	Unspecified
Whiteboard:
Fixed In Version:	dnf-4.7.0-1.fc33	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-05-03 01:48:16 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.