Comment 4 for bug 1674193

I see problems with Ubuntu Core 16 in a VM (ie, with apparmor enabled). There the core snap is trying to access /run/snapd.socket:

Mar 7 15:08:47 snappy-16-amd64 kernel: [ 343.634033] audit: type=1400 audit(1488899327.930:9): apparmor="DENIED" operation="create" profile="snap.core.hook.configure" pid=1382 comm="snapctl" family="inet" sock_type="stream" protocol=6 requested_mask="create" denied_mask="create"
Mar 7 15:08:47 snappy-16-amd64 kernel: [ 343.634141] audit: type=1400 audit(1488899327.930:10): apparmor="DENIED" operation="create" profile="snap.core.hook.configure" pid=1382 comm="snapctl" family="inet6" sock_type="stream" protocol=6 requested_mask="create" denied_mask="create"
Mar 7 15:08:47 snappy-16-amd64 kernel: [ 343.634179] audit: type=1400 audit(1488899327.930:11): apparmor="DENIED" operation="create" profile="snap.core.hook.configure" pid=1382 comm="snapctl" family="inet6" sock_type="stream" protocol=6 requested_mask="create" denied_mask="create"
Mar 7 15:08:47 snappy-16-amd64 kernel: [ 343.649750] audit: type=1400 audit(1488899327.946:12): apparmor="DENIED" operation="open" profile="snap.core.hook.configure" name="/run/snapd.socket" pid=1382 comm="snapctl" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0

This is https://bugs.launchpad.net/snapd/+bug/1674484 and https://bugs.launchpad.net/snappy/+bug/1644573.

On OpenSuse I suspect what is happening is that because apparmor is disabled, /run/snapd.socket is not denied so then the bind() is tried and there is a seccomp denial.

I think the real questions are understanding why /run/snapd.socket is being used, and why is bind() being used. The default template allows use of /usr/bin/snapctl and /run/snapd-snap.socket, but the core snap and by the looks of it, other snaps like network-manager, wpa-supplicant are using snapctl which generates a denied access to /run/snapd.socket. Is this intentional? Is snapctl attempting to open /run/snapd.socket and if it can't it falls back to /run/snapd-snap.socket (if so, I would argue this is probably the wrong behavior since it creates a lot of confusion due to the noisy denial)? Is the configure hook working correctly anywhere?

*If* the core snap has legitimate access to /run/snapd.socket, then perhaps its configure hook should also 'plugs: [ snapd-control ]'.

All that said, it looks like core r1530 now plugs 'network-bind'. I'm not sure if that was to address this bug-- if it wasn't, then the inet apparmor denials and the bind seccomp call will all be addressed by this change.