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'
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 985/ dnsmasq)
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.
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.
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).
Just to satisfy my curiosity. In what kind of product is dnsmasq used? I think it is not installed in default installation.
FEDORA-2022-f974e1a80a has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-f974e1a80a
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.
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.
It's in Silverblue & Kinoite too and likely in IoT.
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.