[Bug 1186711] New: apparmor change breaks dnsmasq dhcp-script execution
http://bugzilla.opensuse.org/show_bug.cgi?id=1186711 Bug ID: 1186711 Summary: apparmor change breaks dnsmasq dhcp-script execution Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: AppArmor Assignee: suse-beta@cboltz.de Reporter: michael@actrix.gen.nz QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- I did a zypper dup on a aarch64 Raspberry-Pi to take it from TW release 20210429 to 20210517. After the update+reboot my dhcp-script=/usr/local/sbin/dhcp-script stopped working (configured in /etc/dnsmasq.d/local.conf). Using journalctl I can see the following error: Jun 01 17:37:15 luna9 dnsmasq[27120]: failed to execute /usr/local/sbin/dhcp-script: Permission denied After some investigation of permissions via ls and aa-logprof, I found I could get the script running again by editing /etc/apparmor.d/local/usr.sbin.dnsmasq and adding the following lines: /usr/local/sbin/dhcp-script Uxr, From /var/log/zypp/history I can see that dnsmasq was not updated by the dup, so that makes me suspect that problem is due to an update to apparmor-profiles or related packages. Has anything changed recently in apparmor that could have caused dnsmasq to not be able to execute a script unless it has an entry in /etc/apparmor.d/local/usr.sbin.dnsmasq? (In diagnosing this error I was also puzzled how the script was working in the first place. I found my original script was only accessible by root, but I then noticed dnsmasq parent process is root owned, so presumably the script is being run as root and not as the dnsmasq user.) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1186711
http://bugzilla.opensuse.org/show_bug.cgi?id=1186711#c1
Christian Boltz
http://bugzilla.opensuse.org/show_bug.cgi?id=1186711
http://bugzilla.opensuse.org/show_bug.cgi?id=1186711#c2
--- Comment #2 from Michael Hamilton
The last big(ger) change was the update to AppArmor 3.0.1 - but that was already on Dec 02 2020. Since then, there were a few small patches added (all adding more permissions) and a few small packaging changes - nothing that could explain your dnsmasq problems.
What's the previous rule you had to allow running your script? (The shipped dnsmasq profile never allowed to run anything in /usr/local/, so if your answer is "no previous rule", then please check your logs if that "failed to execute" message is really new.)
Thanks for the prompt attention to this issue. I previously had no rules and the script was working fine (it checks for any unexpected MAC addresses requesting IP addresses and sends an email in case I need to investigate). After the dup, the script no longer worked and I then found the errors in the journal (no similar errors prior to the dup). As I explained, it was at this point I started investigating permissions+apparmor and found that adding a rule could restore the previous behavior. This Raspberry-Pi's sole task is to run dnsmasq (with DHCP) in my home network. Aside from issuing a dup no other changes were made prior to the issue. This is not particularly important to me. Feel free to close or park the case if it is inexplicable. I'm happy to use a rule to achieve the past behavior. I mainly logged the issue in case it indicated potential for issues with other daemons that might also run scripts. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1186711
http://bugzilla.opensuse.org/show_bug.cgi?id=1186711#c3
Christian Boltz
participants (1)
-
bugzilla_noreply＠suse.com