AppArmor: cupsd not allowed to send signals to third_party

[Felix Geyer]

The cups 1.7.5-3 AppArmor profile has this rule which seems to be ineffective:
  signal (receive, send) peer=third_party,

I get this denial log entry when (re)installing cups:
audit: type=1400 audit(1412239287.417:110): apparmor="DENIED" operation="signal" profile="/usr/sbin/cupsd" pid=28964 comm="cupsd" requested_mask="send" denied_mask="send" signal=term peer="/usr/sbin/cupsd//third_party"

Changing it to the absolute profile name seems to work:
  signal (receive, send) peer=/usr/sbin/cupsd//third_party,

I guess apparmor_parser can't distinguish between a profile named third_party and a subprofile named third_party.

[Jamie Strandboge (jdstrand)]

Thanks for the report. I'll get this fixed soon.

[Didier Raboud (odyx)]

@jdstrand: Please make sure to avoid double-work and provide your work as patches against the Debian src:cups package (either through filing Debian bugs or by providing patches as branches directly on the git repository. Work "on the Ubuntu side" while I'm fighting for years to keep the diff as minimal as possible is… annoying.

[Jamie Strandboge (jdstrand)]

Didier, sure. Actually, I already took a todo to do just this but wanted to think about the fact that Debian doesn't support the signal rule and how to best handle it before submitting.

[Launchpad Janitor (janitor)]

This bug was fixed in the package cups - 1.7.5-3ubuntu1

---------------
cups (1.7.5-3ubuntu1) utopic; urgency=medium

  * debian/local/apparmor-profile:
    - fix peer on signal rule to use /usr/sbin/cupsd//third_party
      (LP: #1376611)
    - temporarily use attach_disconnected to work around LP: #1373070. This
      should be undone once 1373070 is properly fixed
 -- Jamie Strandboge <email address hidden> Thu, 02 Oct 2014 08:22:36 -0500