Summary = probeAppArmor()
<zyga> until you reboot and snapd considers this
<jdstrand> appArmorParserFeatures = probeAppArmorParser()
<jdstrand> what is weird though, is if this is the issue, then why don't I see denials from probeAppArmor?
<jdstrand> I only see denials for probeAppArmorParser
<zyga> I think we allowed the former
<jdstrand> I looked in the template. let me look again
<zyga> oh, in that case I don't know
<jdstrand> also, I was really surprised that snap run is doing all these checks
<jdstrand> it isn't like it can do anything with the result
<zyga> I think we d
<zyga> we spin and wait
<zyga> that's the purpose of system key there
<jdstrand> and we are adding a bunch of stat()s and an exec() to the snap run
<jdstrand> hmm
<jdstrand> I definitely didn't mean for apparmor_parser to be called every time that an app was run
<zyga> right
<jdstrand> quite the opposite. I didn't even want it run every time a profile was compile
<zyga> I think this falls under the idea I had a while ago with "facts" in /var/lib/snapd/facts - that would be written by snapd and interrogated by other parts of the stsack
<jdstrand> I wanted it precisely once when snapd started :)
<jdstrand> and I thought that was what happened with system-key
<zyga> mmm, not quite
<zyga> you need to be able to compute the system key
<jdstrand> well, clearly
<zyga> in snap-run
<zyga> and quickly too as you now learned
<jdstrand> we need to short circuit this or move it
<jdstrand> I mean we could add a rule, but blech, I don't want this-- it is only useful for profile generation
<zyga> I agree
<zyga> hmmm hmm
<jdstrand> snap run can literally do nothing with the information
 * pstolowski lunches
<zyga> jdstrand: if you need me for this just ask, otherwise I'll be going through per user mount namespaces
<jdstrand> yeah, I don't see /sys/kernel/security/apparmor/features in the template
<jdstrand> zyga: thanks, I'll discuss with mvo and we can decide from there
<jdstrand> it is definitely denied: $ ls /sys/kernel/security/apparmor/features/
<jdstra