interfaces/apparmor/template.go: adjust /dev/shm to be more usable

[jdstrand]

Allow snap-specific access to files and directories in /dev/shm. The previous
implementation of /dev/shm/snap/SNAP_NAME/SNAP_REVISION was problematic
because it didn't handle shm_open() at all and was uncomfortable for developers
to use with open(). This allows file access in /dev/shm for shm_open() and
files in subdirectories for open().

[zyga]

+1, thanks :-)

[niemeyer]

Let's please hold this until we discuss next week.

[mvo5]

I close tihs for now based on the comment from gustavo. Please reopen once this was discussed.

[jdstrand]

Reopening since last week went by. This is not intended to address https://bugs.launchpad.net/snappy/+bug/1577514 which I agree does require more discussion-- did that happen?

This PR stands separate from the bug though and it isn't clear to me why this was closed; this update provides essentially equivalent access as before except it fixes shm_open() and more flexible snap-specific accesses are allowed. Ie, snaps may now use shm_open() if they specify snap..* (which prior to this PR a snap could not use shm_open() at all) and also allows snaps to create snap-specific files and directories in /dev/shm. Neither of these opens up the policy in overlapping snap specific ways.

[niemeyer]

retest this please

[niemeyer]

We discussed this last week, and the agreement was two-fold:

• We'll white list /dev/shm/snap.$SNAP_NAME.* for private use by the snap
• We'll white list /dev/shm/<prefix>-* via interfaces on clear cases (e.g. pulseaudio)

So this branch is good to move forward