Bug 2142368

Summary:	unbound-libs 1.16.3-3 fails to install root.key with correct permissions
Product:	[Fedora] Fedora	Reporter:	Frederik Boster <frederik>
Component:	unbound	Assignee:	Petr Menšík <pemensik>
Status:	ASSIGNED ---	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	37	CC:	aegorenkov.91, akhaitovich, alex.ploumistos, paul.wouters, pemensik, pj.pandit
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		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:
Bug Blocks:	2149036

Description Frederik Boster 2022-11-13 13:19:31 UTC

Description of problem:
When the package unbound-libs is installed via dnf with the option "--setopt=install_weak_deps=false" the file "/var/lib/unbound/root.key" is owned by user "root" although it should be owned by user "unbound".

The following error message is displayed while installing unbound-libs-1.16.3-3:
>  Preparing        :                                     1/1 
>  Installing       : protobuf-c-1.4.1-2.fc37.x86_64        1/2 
>  Installing       : unbound-libs-1.16.3-3.fc37.x86_64     2/2 
> warning: user unbound does not exist - using root
> warning: group unbound does not exist - using root
> warning: user unbound does not exist - using root
> warning: group unbound does not exist - using root
>
>  Running scriptlet: unbound-libs-1.16.3-3.fc37.x86_64     2/2 
>  Verifying        : protobuf-c-1.4.1-2.fc37.x86_64        1/2 
>  Verifying        : unbound-libs-1.16.3-3.fc37.x86_64  

The creation of the user / group "unbound" is being done in the stage [%pre anchor](https://src.fedoraproject.org/rpms/unbound/blob/7b3bfe9b4de3413a6e74e989011fe95ee421746a/f/unbound.spec#_344), which would require unbound-anchor to be installed beforehand.

Version-Release number of selected component (if applicable):
1.16.3-3


How reproducible:
always

Steps to Reproduce:
1. Start a container with the image registry.fedoraproject.org/fedora:37
2. Execute "dnf install --setopt=install_weak_deps=false unbound-libs"

Actual results:
The file "/var/lib/unbound/root.key" is owned by user / group "root".

Expected results:
The file "/var/lib/unbound/root.key" should be owned by user / group "unbound".

Additional info:
This issue prevents unbound to be installed to a "scratch" container image with the following command:
> dnf install --setopt=install_weak_deps=false --releasever=37 --setopt=tsflags=nodocs --nodocs --assumeyes --installroot "${CONTAINER_MOUNT}" unbound

The same error message is displayed in this case:
> [...]
>   Installing       : unbound-libs-1.16.3-3.fc37.x86_64   70/73 
> warning: user unbound does not exist - using root
> warning: group unbound does not exist - using root
> warning: user unbound does not exist - using root
> warning: group unbound does not exist - using root
>
>  Running scriptlet: unbound-anchor-1.16.3-3.fc37.x86_64  71/73 
>  Installing       : unbound-anchor-1.16.3-3.fc37.x86_64  71/73 
>  Running scriptlet: unbound-anchor-1.16.3-3.fc37.x86_64  71/73 
>  Installing       : openssl-1:3.0.5-3.fc37.x86_64        72/73 
>  Installing       : unbound-1.16.3-3.fc37.x86_64         73/73 
>  Running scriptlet: unbound-1.16.3-3.fc37.x86_64         73/73 

When unbound is started in the container directly as user "unbound" the following error message is displayed and unbound stops:
> unbound[1:0] fatal error: rename(/var/lib/unbound/root.key.1-0-55b55d7e3f10 to /var/lib/unbound/root.key): Operation not permitted

Comment 1 Petr Menšík 2023-01-02 20:22:01 UTC

Yes, I have noticed this when investigating bug #2149036. It will be fixed soon, I am testing the fix on my copr repository:

https://copr.fedorainfracloud.org/coprs/pemensik/unbound/

Comment 2 Alexander Ploumistos 2023-01-19 20:17:12 UTC

I was too late to comment in bodhi, but there's still an issue when upgrading from unbound-libs-1.17.0-1.fc37 to unbound-libs-1.17.1-1.fc37:

[…]
  Running scriptlet: unbound-libs-1.17.1-1.fc37.x86_64                      13/72 
  Upgrading        : unbound-libs-1.17.1-1.fc37.x86_64                      13/72 
warning: /var/lib/unbound/root.key saved as /var/lib/unbound/root.key.rpmsave
[…]


ls -alh /var/lib/unbound/
total 12K
drwxr-xr-x.  2 unbound unbound 4.0K Jan 19 21:23 .
drwxr-xr-x. 54 root    root    4.0K Dec 25 13:25 ..
lrwxrwxrwx.  1 root    root      36 Jan 16 17:43 root.key -> ../../../etc/unbound/dnssec-root.key
-rw-r--r--.  1 unbound unbound  759 Jan 19 00:00 root.key.rpmsave


What is the proper resolution here?

Comment 3 Frederik Boster 2023-01-19 21:27:17 UTC

@alex.ploumistos that is unrelated to this issue.

"What are rpmnew & rpmsave files?": https://access.redhat.com/solutions/60263

Comment 4 Alexander Ploumistos 2023-01-19 21:38:08 UTC

I thought that root.key should belong to unbound and not root, was that not the source of your issue?

Comment 5 Petr Menšík 2023-06-09 11:44:41 UTC

Oh, there seems to be unseen issue when upgrading. Even after I restart unbound-anchor.service and create therefore modified root.key, after upgrade it resets back to symlink pointing to /etc/unbound/dnssec-root.key. That is not what it were intended and has to be fixed.

Comment 6 Petr Menšík 2023-06-09 11:51:14 UTC

What belongs to root is just initial symlink pointing to /etc/unbound/dnssec-root.key. It should be removed when unbound-anchor.service runs and replaced by unbound user owned file, which is managed by the unbound-anchor.service (or unbound.service). /etc/unbound/dnssec-root.key is owned by root, because any unbound service should not modify it. It does not even have permission to do so, which is intentional.

But comment #5 needs to be fixed, updates should keep modified file.