Overriding seccomp policy: shm_open

[Jacob Zimmermann]

> shm_open() is allowed in the default policy for seccomp and if the path conforms
> to this from the default policy for apparmor, then there should be no issues:
>
>   # App-specific access to files and directories in /dev/shm. We allow file
>   # access in /dev/shm for shm_open() and files in subdirectories for open()
>   /{dev,run}/shm/snap.@{SNAP_NAME}.** mrwlkix,
>
> I suspect you need to adjust hatari to use (perhaps conditionally if SNAP env
> var is set, up to you) shm_open("snap.hatari.XXXXXX", ...) or similar.

Ok I found it, in fact it was hatari trying to connect to pulseaudio.
Adding pulseaudio to the plugs list solved the problem.

Still, I wonder:

1) So is the moral of the story that there is no mechanism for a package
maintainer to customise the security policy applicable to an individual
package? That seems odd.

2) Assuming that it was necessary to patch hatari like Jamie suggested,
what is the idiomatic way to apply a patch to upstream sources before
compiling?

Thanks
Jacob