Bug 1640285

Summary:	[RFE] unbound: use systemd features, drop privileges and enable ABRT
Product:	[Fedora] Fedora	Reporter:	Petr Menšík <pemensik>
Component:	unbound	Assignee:	Paul Wouters <paul.wouters>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	dominik, fedora, pemensik, pj.pandit, pwouters
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-07-06 19:15:38 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:
Bug Depends On:	1640259
Bug Blocks:

Description Petr Menšík 2018-10-17 18:51:09 UTC

Description of problem:
When trying to find a reason why ABRT did not report any issue with unbound for bug #1562594, I found dropping user privileges from unbound without fork prevents kernel dumps of unbound.

Version-Release number of selected component (if applicable):
unbound-1.8.1-1.fc30

How reproducible:
reliable

Steps to Reproduce:
1. dnf install unbound abrt-cli-ng
2. systemctl restart unbound
3. kill -SIGSEGV $(systemctl -p MainPID show unbound | cut -d= -f2)
4. abrt list

Actual results:
No crash is recorded, kernel or abrt does not report anything

Expected results:
Crash with backtrace is recorder and can be submitted as bug.

Additional info:
Upstream added some neat features to unbound. I think --enable-systemd should be added to build and systemd service type changed from Type=simple to Type=notify. It would be able to report failed start of a service and state changes.

Also it is desirable to drop most of privileges before even running unbound.

It would require change from username: "unbound" to username: "". Then add into systemd service something like this:
[Service]
User=unbound
CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_SYS_CHROOT CAP_SYS_RESOURCE CAP_NET_ADMIN CAP_DAC_READ_SEARCH
AmbientCapabilities=CAP_NET_BIND_SERVICE CAP_SYS_CHROOT CAP_SYS_RESOURCE CAP_NET_ADMIN CAP_DAC_READ_SEARCH

Such default configuration would enable ABRT reporting. And it would be more secure at the same time.

When process changes effective uid, then it would no longer dump on crash. Unless workaround mentioned in bug #1562594 comment #34 is used.

Comment 1 Petr Menšík 2018-10-17 18:57:02 UTC

Note: CAP_DAC_READ_SEARCH is probably unnecessary, but it is required for now because of bug #1640259. When it is fixed, it should no longer be necessary. It should be possible to use systemd Limits setting to not require CAP_SYS_RESOURCE as well. Not sure if it is worth the hassle.

Comment 2 Paul Wouters 2019-08-27 14:13:02 UTC

I have to check if systemd support can be compiled in without enabling socket activation support (which is broken causing crashes, and makes no sense)

It seems the config only has one option, use-systemd: yes|no   which claims to enable socket activation.

Comment 3 Fedora Admin user for bugzilla script actions 2021-04-26 12:41:49 UTC

This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.

Comment 4 Paul Wouters 2023-01-13 23:43:09 UTC

I don't think anything has changed yet (just reproduced it still). But I still believe socket activation is really bad and it was causing crashes.

If someone wants to split the --use-systemd into two, one for core systemd and one for socket activation, we could enable parts of this to fix the core dump issue

Comment 5 Paul Wouters 2023-07-06 19:15:38 UTC

Guess it was done anyway so I'll close this bug as current release. This might trigger new issues where various DNS deaemons fight over who gets to run when multiple ones do socket activation, and lets hope socket activation no longer causes crashes.