I've been writing some AppArmor profiles and with each new profile I encounter more advanced rules that I haven't seen before.

In this case I'm creating profile for PulseAudio. I also had a profile for SMPlayer, but when I created the PulseAudio profile, AppArmor said something like this to me when I wanted to watch some movie in SMPlayer:

kernel: audit: type=1400 audit(1505370398.880:1005): apparmor="DENIED" operation="capable" profile="/usr/bin/smplayer" pid=40033 comm="pacmd" capability=19  capname="sys_ptrace"
Sep 14 08:26:38 morfikownia kernel: audit: type=1400 audit(1505370398.880:1006): apparmor="DENIED" operation="ptrace" profile="/usr/bin/smplayer" pid=40033 comm="pacmd" peer="/usr/bin/pulseaudio"

This can be fixed by adding the following to the SMPlayer profile:

  capability sys_ptrace,
  ptrace (trace) peer=/usr/bin/pulseaudio,

But I have two questions about this:

  1. Why does SMPlayer need the rules now? I have its profile for a while, and SMPlayer never asked for the rules. I know that it's because of creating the profile for PulseAudio, but can anyone explain why?

  2. What do the rules actually mean? What would happen when I didn't add them? SMPlayer seems to work just fine without the CAP and ptrace rule.


AppArmor documents ptrace rule in their wiki. Reading certain files in /proc/<pid> can cause the trace request denial message in your logs.

From your log excerpt it looks like pulseaudio (comm=pacmd, profile /usr/bin/pulseaudio) is denied access, and the generated rule would allow the access (I am not familiar enough with pulseaudio details to answer why exactly this happens). If you recently enabled an AppArmor profile for pulseaudio, it would explain why you didn't get this audit message before.

You do not need to allow the access, if you do not have (or notice) any issues. To stop AppArmor from filling your logs you can create a deny rule. Access denied by deny rules do not generate messages in the log:

deny ptrace (trace) peer=/usr/bin/pulseaudio,

However if you decide to allow the access instead, you should first check if granting only ptrace (trace) peer=/usr/bin/pulseaudio is sufficient. Adding capability sys_ptrace adds a capability rule for SMPlayer, which quite likely is not required.

  • Hmm... to be honest I don't know what to think about it. Only SMPlayer needs this CAP. I have multiple A/V players (vlc, mpv, amarok) -- they work fine and don't need additional rules. I also have mpv configured in SMPlayer as a multimedia engine. I think I leave those 2 rules blocked since there's no signs to enable them (the app works fine at least for now). Maybe someone will know what is best in this case, if so I'll reconsider this choice. :) – Mikhail Morfikov Sep 14 '17 at 9:29
  • It's pulseaudio's apparmor profile which causes the denial, not your player's. See the documentation example (T being your media player and P being pulseaudio). Perhaps I should try to clarify this better in my answer? – sebasth Sep 14 '17 at 13:53
  • I know what's wrong. The example is for AppArmor v3. But currently in Debian Sid I have installed 2.11.0-10 and probably that's why this works a little bit different. – Mikhail Morfikov Sep 14 '17 at 19:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.