A BIND/named server running can run its own chroot environment. This functionality is provided by the "bind-chroot" RPM package. The package contains a helper service "named-chroot-setup" which runs a shell script (/usr/libexec/setup-named-chroot.sh) which - based on a file list stored in /etc/named-chroot.files - creates the required chroot environment. It does so mainly by bind-mounting source files from the filesystem to the named's chroot. E.g. the /usr/share/named directory will be bind-mounted to /var/named/chroot/usr/share/named.

However, there is also a configuration file for the "systemd-tmpfiles" service in that package. The file is named /usr/lib/tmpfiles.d/bind-chroot.conf. It contains instructions to create a chroot environment for the named server. Basically it duplicates the work of the mentioned "named-chroot-setup" service. I'm not sure if it was intended that two different means are used for the same goal.

Further, they are not exactly duplicates and they interact in an unexpected way. The directory /usr/share/named belongs to the "bind-chroot" RPM and is shipped owned by root:named, mode 0750 (rwxr-x---). The directory /var/named/chroot/usr/share/named is controlled by the /usr/lib/tmpfiles.d/bind-chroot.conf and the ownership is set to root:root. As explained above, when the named-chroot is running, those two directories are identical due to the mount --bind call. When a "systemd-tmpfiles --create" command is run, the group ownership of /usr/share/named directory will be overwritten from named to root group. The next time the named-chroot service is started, the named server running under named UID:GID will be denied access to that directory. There some auxilliary zone files are stored. Short error log example:
named: zone 0.in-addr.arpa/IN/internal: loading from master file /usr/share/named/named.empty failed: permission denied
named: zone 0.in-addr.arpa/IN/internal: not loaded due to errors.

The last piece of the puzzle is that "systemd-tmpfiles --create" can be run by RPM scriplets and triggers when a fully unrelated package is updated. If the new package updates to /usr/lib/tmpfiles.d/, the systemd package has a filetrigger for that directory.



Reproducible: Always

Steps to Reproduce:
1. configure and run named-chroot
2. check that GID of /usr/share/named is named
3. run "systemd-tmpfiles --create" directly OR e.g. "dnf reinstall man-db" which will 
run that command behind the scenes

Actual Results:
GID of /usr/share/named is suddenly root


Expected Results:
unchanged GID of /usr/share/named

Additional Information:
This report is a summary of https://discussion.fedoraproject.org/t/installing-a-package-breaks-unrelated-package-how-to-debug-rpm-scripts/192208 where several people contributed.