Package: kea-common Version: 3.0.3-2 Severity: minor X-Debbugs-Cc: [email protected]
Dear Maintainer, After upgrading kea-common to 3.0.3-2, directory /etc/kea is forced to mode 0750 via /usr/lib/tmpfiles.d/kea-common.conf. Due to the nature of systemd-tmpfiles, if the system admin tries to set /etc/kea to another mode like 0755, they will find after the next boot that their chmod has been quietly reverted. In practice, this means you now need to become root or _kea just to *read* your own, local, system-specific Kea config(s). Admins can work around this by, for example: (1) symlinking /etc/tmpfiles.d/kea-common.conf to /dev/null, (2) creating /etc/tmpfiles.d/kea-common.conf as a regular file and force the particular mode you want, (3) adding your regular user account as a member of the _kea system group (probably a no-no), (4) overriding kea-dhcp*-server.service to start Kea with '-c /custom/location/kea.conf' (prone to failure on future dist-upgrades), or (5) dpkg-diverting /usr/lib/tmpfiles.d/kea-common.conf. According to the commit [1] where this behaviour was implemented, the intention was to facilitate "factory resetting a system and recreating /etc/ on boot". Since /etc has not been deleted in my case, and I am not performing a factory reset, it seems like forcing a mode and owner to an *existing* directory within /etc could potentially be unintentional. On the other hand, if this change in Debian-specific behaviour for Kea *is* intentional, may I ask what the justification is for undermining the purpose of the system-specific config area that is /etc on every (regular, non-factory-resetting) boot? Also, I thought the purpose of systemd-tmpfiles was to manage temporary/volatile files, not permanent config files. Have I misunderstood something there? Shipping with 0750 as default mode is one thing. But, as a system admin, I should be able to adjust that default mode according to my own workflow and preferences, without having to also negate systemd-tmpfiles just to make my mode change on *my* local system-specific config directory stick. For my particular use case, I would very much like to avoid having to run my DHCP compliance- and sanity-checking scripts as root, or as the _kea user for that matter, since both have write permissions which my scripts do not need and which they definitely should not have. If this change sticks in Forky, I will likely apply one of the former mentioned workarounds by the time Forky reaches stable and I upgrade my Trixie-powered Kea nodes to it. I can live with that, but having to do so in the first place seems awkward, confusing and annoying. Thanks for all your hard and good work. Best regards Aka Sikrom [1] https://salsa.debian.org/debian/isc-kea/-/commit/85d32fc3570bb764107f60ed0969ac28745c7022 -- System Information: Debian Release: forky/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.12.95+deb13-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages kea-common depends on: ii libc6 2.42-17 ii libgcc-s1 16.1.0-2 ii liblog4cplus9 2.1.2-2 ii libmariadb3 1:11.8.8-1 ii libpq5 18.4-1+b1 ii libssl3t64 3.6.3-1 ii libstdc++6 16.1.0-2 ii systemd [systemd-tmpfiles] 261.1-3 kea-common recommends no packages. kea-common suggests no packages. -- no debconf information
