Bug 2104973

Summary:	dnsmasq: troubles with ownership of /etc files and dynamic group "dnsmasq"
Product:	[Fedora] Fedora	Reporter:	Luca BRUNO <lucab>
Component:	dnsmasq	Assignee:	Petr Menšík <pemensik>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	36	CC:	aegorenkov.91, code, dns-sig, dougsland, pemensik, travier, veillard
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	dnsmasq-2.86-10.fc36	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-07-21 16:38:34 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 Luca BRUNO 2022-07-07 15:31:22 UTC

The "dnsmasq" package is currently shipping some files and directories under /etc which are owned by the "dnsmasq" group:
```
$ # stat /etc/dnsmasq.* | grep 'File\|Gid'
  File: /etc/dnsmasq.conf
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (  985/ dnsmasq)
  File: /etc/dnsmasq.d
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (  985/ dnsmasq)
```

However the package does create the "dnsmasq" user/group with a dynamic ID at install time:
```
u dnsmasq - "Dnsmasq DHCP and DNS server" /var/lib/dnsmasq
```

This means that across different installs/composes the numeric GID of those  entries may vary arbitrarily (in the example above it got "985").

This poses a problem from the point of view of OS content reproducibility.
It also causes issues to systems doing out-of-band composes (e.g. ostree or other image-based technologies).

For these reasons, it would be better to adopt a different arrangement for those  files/group.

Overall it looks like the group ownership could be changed to the standard "root" one.
If I'm understanding this correctly, the "group" permissions are exactly the same as the ones for "other", so there is nothing gained from having the group-ownership set to the "dnsmasq" group instead of "root".
This looks like the simplest way to fix this issue.

If that is not possible for some reason, we can alternatively consider getting static UID and GID allocated for the "dnsmasq" user/group in Fedora.

Comment 1 Petr Menšík 2022-07-07 16:22:01 UTC

I guess it would work with /etc/ files, where is nothing writeable by daemon and it should not be allowed to modify it. It can change to root there. But I think /var/lib/dnsmasq still needs to be writeable also by unprivileged daemon. I am not sure if that is written always, but dhcp leases are stored in /var/lib/dnsmasq. It should be modifiable by non-privileged daemon, after it has dropped permissions.

But dnsmasq uses helper forked process in some cases, I am not sure which of them handles leases file. It is also possible to have lease scripts writing arbitrary data into its directory. libvirt does not use that, but some other technology might.

Comment 2 Luca BRUNO 2022-07-08 08:54:30 UTC

Thanks for the quick feedback!

> I guess it would work with /etc/ files, where is nothing writeable by daemon and it should not be allowed to modify it. It can change to root there.

Great to hear, then I'd be very happy if you could push this change to F37/F36 already.

> But I think /var/lib/dnsmasq still needs to be writeable also by unprivileged daemon.

Indeed, I only mentioned /etc entries because that's the main pain-point.

For content under /var, the group ownership isn't exactly a problem.
For example speaking of ostree, entries under /var are not really shipped as part of the OS as they can get created through systemd-tmpfiles fragments.
For the dnsmasq package, the empty directory can automatically be translated into the following fragment:
```
$ cat /usr/lib/tmpfiles.d/pkg-dnsmasq.conf 
d /var/lib/dnsmasq 0755 root dnsmasq - -
```
This works because systemd-sysusers makes sure that the "dnsmasq" group exists before systemd-tmpfiles creates the directory.
The "pkg-dnsmasq.conf" file is generated by the rpm-ostree internal logic when importing the package content into ostree.
But if you are generally concerned about about that directory, you could directly ship the tmpfiles.d fragment in the package (or upstream) and turn that directory into a %ghost entry (I think, I haven't tried).

Comment 3 Petr Menšík 2022-07-08 20:46:26 UTC

Just to satisfy my curiosity. In what kind of product is dnsmasq used? I think it is not installed in default installation.

Comment 4 Fedora Update System 2022-07-08 21:27:15 UTC

FEDORA-2022-f974e1a80a has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-f974e1a80a

Comment 5 Fedora Update System 2022-07-09 01:13:57 UTC

FEDORA-2022-f974e1a80a has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-f974e1a80a`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-f974e1a80a

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 6 Luca BRUNO 2022-07-11 07:45:32 UTC

Thanks for the quick turnaround on this ticket!

> Just to satisfy my curiosity. In what kind of product is dnsmasq used? I think it is not installed in default installation.

The 'dnsmasq' package is a dependency of the podman stack (through podman -> podman-plugins -> dnsmasq), and the 'dnsmasq' binary is also used by NetworkManager in some configurations (e.g. with 'dns=dnsmasq').

As such, the package is (at least) part of Fedora CoreOS base images.
See https://github.com/coreos/fedora-coreos-tracker/issues/519 for more context.

Comment 7 Timothée Ravier 2022-07-11 10:40:32 UTC

It's in Silverblue & Kinoite too and likely in IoT.

Comment 8 Fedora Update System 2022-07-21 16:38:34 UTC

FEDORA-2022-f974e1a80a has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.