The two snap-confine denials shouldn’t affect this (I’ve taken a todo to fix the uevent denial, the user-dirs.conf is already on the list to look at). The read on /etc/xdg/user-dirs.conf also should not affect the exit (I suspecct all of these happen on start, not at exit).
You said before the issue is resolved if you connect process-observe, is that correct? (I don’t see a denial related to process-observe in your last paste).
https://github.com/snapcore/snapd/pull/4097 has a fix for the user-dirs.conf denial. I’ve requested it for 2.29.
The uevent denial has a fix in https://github.com/snapcore/snapd/pull/4098. I’ve requested this for 2.29.
From Discord ptrace AppArmor denials (that topic was actually a repetition of what I said earlier in this topic oops):
@wimpress can you ask the Discord devs to adjust or is that unlikely to happen and we should again request auto-connecting this interface?
I was reminded that there was no vote for system-observe. I’d like to hear back from upstream before casting my vote.
What could be causing the following denial?
[ 9217.259134] audit: type=1400 audit(1550748163.700:6490): apparmor="DENIED" operation="capable" profile="snap.discord.discord" pid=5462 comm="Discord" capability=19 capname="sys_ptrace"
[ 9222.258887] audit: type=1400 audit(1550748168.700:6491): apparmor="DENIED" operation="capable" profile="snap.discord.discord" pid=5462 comm="Discord" capability=19 capname="sys_ptrace"
[ 9227.261310] audit: type=1400 audit(1550748173.704:6492): apparmor="DENIED" operation="capable" profile="snap.discord.discord" pid=5462 comm="Discord" capability=19 capname="sys_ptrace"
[ 9242.263344] audit: type=1400 audit(1550748188.704:6493): apparmor="DENIED" operation="capable" profile="snap.discord.discord" pid=5462 comm="Discord" capability=19 capname="sys_ptrace"
[ 9247.264970] audit: type=1400 audit(1550748193.708:6494): apparmor="DENIED" operation="capable" profile="snap.discord.discord" pid=5462 comm="Discord" capability=19 capname="sys_ptrace"
A user says that these aren’t resolved by connecting system-observe and unity7…
Applies to Discord 0.0.8 2019-02-14 (91) on core 16-2.37.2 (6405) (current versions, as of 23/02/2019 15:42 GMT+0) on Ubuntu 18.04.
Try process-control. Ptrace is a debugging thing. You can also try using snappy-debug which will advise relevant interfaces for things it sees being blocked while you run it at the same time as your app:
sudo snap install snappy-debug
snappy-debug.security scanlog
Press ctrl + c to stop it again. Run your application in a second terminal and reproduce the denial - snappy-debug will output its advise in the first terminal.
The new reporter on GitHub has given the following output:
= AppArmor =
Time: Feb 25 16:55:33
Log: apparmor="DENIED" operation="capable" profile="snap.discord.discord" pid=7216 comm="Discord" capability=19 capname="sys_ptrace"
Capability: sys_ptrace
Suggestions:
* adjust program to not require 'CAP_SYS_PTRACE' (see 'man 7 capabilities')
* do nothing if program otherwise works properly
I reckon Discord wants advanced permissions because it observes if games are running and then automatically displays the user on Discord as playing that game. It’s an active status thing. I doubt the problem with Discord’s permissions will be resolved unless snappy and Discord find a way to give Discord more limited fine-grained access to view what processes are running (rather than giving it full process-control)…
Is there any way of silencing the denials so they don’t clutter the journal? I think I must’ve silenced mine at some point because they’re not coming up anymore but I can’t remember how I did that and the reporter wants to know! 
This is discussed in Discord ptrace AppArmor denials. While we can suppress the logging with an explicit deny rule, we cannot later undo that rule. What is really needed is an apparmor ‘quiet’ rule that allows suppressing the log without explicitly denying it, and then we need to design in snapd what log suppression should like like.
That said, we’ve recently devised a method of suppressing ptrace under certain conditions (https://github.com/snapcore/snapd/pull/5980). It looks like deny capability ptrace could be added to ptraceTraceDenySnippet. I’ll consider this in the next batch of policy updates.
FYI, https://github.com/snapcore/snapd/pull/7019 for adding deny capability ptrace to ptraceTraceDenySnippet
@Ads20000 - nothing. The explicit deny rule is in the default template:
Keep in mind that is only for ‘ptrace (trace)’ rules and not ‘ptrace (read)’. Can you please paste some representative denials and the output of snap connections discord?
Without any manual connections
Apr 16 20:37:23 adam-thinkpad-t430 audit[30224]: AVC apparmor="DENIED" operation="ptrace" profile="snap.discord.discord" pid=30224 comm="Discord" requested_mask="read" denied_mask="read" peer="unconfined"
Apr 16 20:37:23 adam-thinkpad-t430 audit[30224]: AVC apparmor="DENIED" operation="open" profile="snap.discord.discord" name="/proc/29618/cmdline" pid=30224 comm="Discord" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Running snap connect discord:system-observe gets rid of the denials (I’m aware there’s security issues with this but currently the denials are not silenced out-of-the-box)
( I would use nice dropdown things instead of Ubuntu Pastebin (which may expire eventually) but I actually can’t remember now how I did those 
)
Any progress with silencing of the denials without security compromise?
This is not a security compromise. It is giving information to discord. I think the best path forward is for the discord publisher to request that system-observe be autoconnected or to detail why discord is doing this legitimately or detail what feature to turn off to make the denials stop. Ultimately this is a bug in the discord snap that should be addressed either through auto-connection, code changes or configuration.
We could look into adding an explicit deny for ptrace read on unconfined like we did in https://github.com/snapcore/snapd/pull/7019, but this isn’t going to solve everything (eg, the same sort of denial will pop up for running snaps or system confined processes). Ideally, snapd could use quiet rules or a quiet profile flag to suppress logging for this sort of thing, but this functionality is not yet available in the kernel or apparmor userspace for it to use.
I assume you mean the Discord application developer rather than the snap publisher? Because the snap publisher (snapcrafters) has requested the autoconnection via the OP, just need some +1s from reviewers for it to go through.
Perhaps the easiest thing is for us to use yad (or similar) to do a one-time punch in the face to the user that rich presence won’t work until you connect system-observe. But the downside is the giant logs.
the last update to the discord readme seems to say there discussions with upstream, is there anything can be done to get upstream aka the discord application publisher to request the autoconnection? maybe a request on their uservoice?
This came up again in https://github.com/snapcrafters/discord/issues/23#issuecomment-760365707 where I said (among other things): “there is an upcoming feature regarding apparmor ‘quiet’ rules and profile flags that would be useful. Now that AppArmor 3 is out, we’re closer to being able to implement that. Once done, snapd could add some controls (eg, snap set system:quiet-snap=discord (syntax TBD, but you get the idea) that could enable people to silence the denials in a manner that doesn’t otherwise affect the policy.”
Now that AppArmor 3 is out and we know we want to vendor AppArmor into snapd to help with our cross distro story, I asked @jjohansen about the quiet profile flag and he said that it is currently scheduled for 3.1, but might get pushed to 3.2 depending on timing and other prioritized work. @alexmurray (cc @mvo and @pedronis) - this would be a pretty neat thing for snapd to do. @lucyllewy also had an interesting idea surrounding default behavior (that I’ll let him comment on).