Bug 2142368 - unbound-libs 1.16.3-3 fails to install root.key with correct permissions
Summary: unbound-libs 1.16.3-3 fails to install root.key with correct permissions
Keywords:
Status: ASSIGNED
Alias: None
Product: Fedora
Classification: Fedora
Component: unbound
Version: 37
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Petr Menšík
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 2149036
TreeView+ depends on / blocked
 
Reported: 2022-11-13 13:19 UTC by Frederik Boster
Modified: 2023-06-09 11:51 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)

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.


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