interfaces/builtin: remove the name=org.freedesktop.DBus restriction in cups-control AppArmor rules #11843
+8
−8
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While testing the CUPS snap, @tillkamppeter noticed that some D-Bus broadcast signals were being blocked by AppArmor.
On closer inspection, the rules related to the
org.cups.cupsd.Notifier
D-Bus interface all had a restriction likepeer=(name=org.freedesktop.DBus,label=...)
. This seemed weird to me, as that name is reserved for dbus-daemon, and these messages are not being sent to or received from the bus. Removing thename=
restriction allowed the messages to be delivered.I asked @alexmurray for his opinion, and he couldn't think of a reason the name conditional was included here either, so I've submitted this PR to remove it.
In this case, there isn't a different D-Bus name that could be used in the rule. The messages are sent by a short lived notifier plugin process:
https://github.com/OpenPrinting/cups/blob/master/notifier/dbus.c
It does not try to own a name, and the clients watching for the signal broadcasts don't match on a well known bus name either.