Hello, I wrote an experimental AppArmor profile for PulseAudio. I also have some profiles for bunch of other apps [1], and the question I want to ask isn't really connected to those profiles, but rather it concerns interactions between some processes and PulseAudio. For instance, I use SMPlayer to watch movies. I also have AppArmor profile for this app, and it's loaded in enforce mode. I've been using this app for some time without any "denied" messages in the system log. After adding the PulseAudio profile to AppArmor (in complain mode so far), I noticed that AppArmor reports the following logs: 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" kernel: audit: type=1400 audit(1505370398.880:1006): apparmor="DENIED" operation="ptrace" profile="/usr/bin/smplayer" pid=40033 comm="pacmd" peer="/usr/bin/pulseaudio" As you can see, these messages concerns the SMPlayer profile and not the PulseAudio profile. This can be solved by adding the following rules to the SMPlayer profile: capability sys_ptrace, ptrace (trace) peer=/usr/bin/pulseaudio, 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? 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. Can anyone cast some light on this? [1] https://github.com/morfikov/files/tree/master/configs/etc/apparmor.d/
