Bug 1113947

Summary:	Add unbound-chroot systemd service for running unbound in the chroot
Product:	[Fedora] Fedora	Reporter:	Tomáš Hozza <thozza>
Component:	unbound	Assignee:	Tomáš Hozza <thozza>
Status:	CLOSED WONTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	20	CC:	fweimer, psimerda, pwouters, shgao, thozza, vonsch
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-07-10 07:58:47 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 Tomáš Hozza 2014-06-27 10:14:20 UTC

Description of problem:
The current unbound package does not support running in a chroot. We could add
a new sub-package with unbound-chroot.service which would start unbound in the
chroot (e.g. /var/lib/unbound).

The subpackage should create and own the chroot filesystem.
The service should:
1. prepare the chroot on start (bind-mount all necessary files into the chroot)
2. start the unbound in chroot
3. unmount all files from the chroot on service stop.

Additional info:
https://open.nlnetlabs.nl/pipermail/dnssec-trigger/2014-June/000327.html

Comment 1 Paul Wouters 2014-06-30 16:04:50 UTC

I strongly prefer NOT to do this. 

Using chroot historically comes with many many problems with include file paths, lock files, pid files and reload/restart problems. This will be worse with unbound-control thrown into the mix. We don't want to deal with copying /etc/unbound/*.d directories into a chroot.

There is nothing that we gain with chroot() that selinux and containers/cgroups does not already offer us.

It was a very conscious decision made when I started packaging unbound to not support chroot().

Please let me know what specific feature chroot would give us that we currently do not have?

Comment 2 Florian Weimer 2014-06-30 16:32:49 UTC

Does Unbound have a fairly restrictive SELinux policy?  If yes, I don't really see that much value in chrooting, especially this isn't as easy as it used to be because of library dependencies and the required state management.  (It would be bad if Unbound keeps running vulnerable binaries because the chroot environment is not updated.)

Comment 3 Tomáš Hozza 2014-07-01 07:38:49 UTC

This is more a placeholder bug for request PJP raised on the dnssec-trigger-list.

I agree that if running unbound in the chroot should complicate things even more
without any benefit, it is not worth it. unbound runs in named_t as BIND. However
I'm no expert to say if it is restrictive enough (although seems reasonable to me).

Comment 4 Tomáš Hozza 2014-07-10 07:58:47 UTC

Since there seems to be no benefit of running unbound in a chroot, but rather more issues I'm closing this as WONTFIX.