Bug 2104973 - dnsmasq: troubles with ownership of /etc files and dynamic group "dnsmasq"
Summary: dnsmasq: troubles with ownership of /etc files and dynamic group "dnsmasq"
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: dnsmasq
Version: 36
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Petr Menšík
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-07-07 15:31 UTC by Luca BRUNO
Modified: 2022-07-21 16:38 UTC (History)
7 users (show)

Fixed In Version: dnsmasq-2.86-10.fc36
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-07-21 16:38:34 UTC
Type: Bug


Attachments (Terms of Use)

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.


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