Description of problem: This had been reported in bug 1663692 two years ago, but apparently has re-surfaced: ============================================ $ grep faci /etc/dnsmasq.d/work.conf log-facility=/var/log/dnsmasq.log $ ls -ldZ /var{,/log{,/dnsmasq.log}} drwxr-xr-x. 1 root root system_u:object_r:var_t:s0 246 Nov 17 02:51 /var drwxr-xr-x. 1 root root system_u:object_r:var_log_t:s0 1230 Nov 17 02:40 /var/log -rw-rw----. 1 dnsmasq dnsmasq system_u:object_r:dnsmasq_var_log_t:s0 5410 Oct 20 10:44 /var/log/dnsmasq.log $ systemctl restart dnsmasq.service Job for dnsmasq.service failed because the control process exited with error code. See "systemctl status dnsmasq.service" and "journalctl -xeu dnsmasq.service" for details. $ journalctl -l | grep dnsm [....] Nov 17 14:11:20 host audit[51617]: AVC avc: denied { dac_override } for pid=51617 comm="dnsmasq" capability=1 scontext=system_u:system_r:dnsmasq_t:s0 tcontext=system_u:system_r:dnsmasq_t:s0 tclass=capability permissive=0 Nov 17 14:11:20 host dnsmasq[51615]: dnsmasq: cannot open log /var/log/dnsmasq.log: Permission denied Nov 17 14:11:20 host dnsmasq[51615]: cannot open log /var/log/dnsmasq.log: Permission denied Nov 17 14:11:20 host systemd[1]: dnsmasq.service: Control process exited, code=exited, status=3/NOTIMPLEMENTED Nov 17 14:11:20 host dnsmasq[51615]: FAILED to start up Nov 17 14:11:20 host systemd[1]: dnsmasq.service: Failed with result 'exit-code'. Nov 17 14:11:20 host audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=dnsmasq comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' $ ausearch -m avc | grep dnsmasq | tail -1 | audit2allow allow dnsmasq_t self:capability dac_override; ============================================ Version-Release number of selected component (if applicable): dnsmasq-2.86-3.fc35.x86_64 How reproducible: Always. Steps to Reproduce: 1. Configure dnsmasq to log its output to a log file 2. Start dnsmasq. 3. dnsmasq is not able to start. Actual results: dnsmasq does not start. Expected results: dnsmasq should start. Additional info: Removing log-facility=/var/log/dnsmasq.log from the configuration makes dnsmasq start just fine.
I think it would be fixed if you keep the file owned and writeable by root, but also by dnsmasq group. Would the issue disappear if you chown root:dnsmasq /var/log/dnsmasq.log? It might open log file handle before it drops privileges and switches to dnsmasq user. It would not be issue if it had all root capabilities, such as ability to write to not owned files (dac_override). Because we do not grant such rights even to root processes, root user or group has to have write ability.
I have checked when log_reopen is called. I can confirm it is called when it still has effective uid 0. My dnsmasq.log permissions have this: -rw-r-----. 1 dnsmasq root 1489 24. lis 16.33 /var/log/dnsmasq.log But it seems it can just create that file once, but not reopen it on another restart. rm -f /var/log/dnsmasq.log $ sudo systemctl restart dnsmasq # ok $ sudo systemctl restart dnsmasq Job for dnsmasq.service failed because the control process exited with error code. See "systemctl status dnsmasq.service" and "journalctl -xeu dnsmasq.service" for details. It seems it should include right to write also to group when creating this file. I am not sure if it should do it always. dnsmasq may run also as unprivileged user directly, where such adding might not be required. But permissions of created file is not configurable. Of course, you may create that file before and apply correct rights before starting dnsmasq. $ sudo chmod g+w /var/log/dnsmasq.log $ sudo systemctl restart dnsmasq # ok I am not sure if this should be fixed in dnsmasq code. First thing is this is ensured by SELinux and systemd on Fedora. It would work if started from command line. It can be corrected by proper logrotate configuration, which is not part of dnsmasq package. I expect journal is usually sufficient.
Created attachment 1843431 [details] candidate patch Always add group writeable bit to log-facility file. It might not always be needed, but is needed if creating new file into /var/log. It succeeds first time, but fails on following restart(s).
Thanks for responding. Yes, removing the file helps, dnsmasq will then create the log file with: -rw-r-----. 1 dnsmasq root system_u:object_r:dnsmasq_var_log_t:s0 7391 Nov 28 17:48 /var/log/dnsmasq.log And indeed, restarting dnsmasq then fails with: dnsmasq: cannot open log /var/log/dnsmasq.log: Permission denied The chmod g+w trick helps, now dnsmasq can indeed be restarted. -rw-rw----. 1 dnsmasq root system_u:object_r:dnsmasq_var_log_t:s0 14013 Nov 28 17:49 /var/log/dnsmasq.log So, this is a good workaround. But yeah, fixing this in dnsmasq would be cool.
Posted upstream, already accepted: https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2022q1/016070.html
Accepted and merged: http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1f8f78a49b8fd6b2862a3882053b1c6e6e111e5c
FEDORA-2022-bc951e2e74 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-bc951e2e74
FEDORA-2022-c180c1560c has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2022-c180c1560c
FEDORA-2022-bc951e2e74 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-bc951e2e74` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-bc951e2e74 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-c180c1560c has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-c180c1560c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-c180c1560c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-bc951e2e74 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-c180c1560c has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.