Calling snapctl with snapd 2.17/2.18 causes AppArmor denials in dmesg because of access to /run/snapd.socket

[Simon Fels]

Calling snapctl from the configure hook from within a snap causes the following denials

[ 6639.038089] audit: type=1400 audit(1481196092.601:73): apparmor="DENIED" operation="create" profile="snap.network-manager.hook.configure" pid=2077 comm="snapctl" family="inet" sock_type="stream" protocol=6 requested_mask="create" denied_mask="create"
[ 6639.038177] audit: type=1400 audit(1481196092.601:74): apparmor="DENIED" operation="create" profile="snap.network-manager.hook.configure" pid=2077 comm="snapctl" family="inet6" sock_type="stream" protocol=6 requested_mask="create" denied_mask="create"
[ 6639.038706] audit: type=1400 audit(1481196092.605:75): apparmor="DENIED" operation="create" profile="snap.network-manager.hook.configure" pid=2077 comm="snapctl" family="inet6" sock_type="stream" protocol=6 requested_mask="create" denied_mask="create"
[ 6639.040053] audit: type=1400 audit(1481196092.605:76): apparmor="DENIED" operation="open" profile="snap.network-manager.hook.configure" name="/run/snapd.socket" pid=2077 comm="snapctl" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0

The hook itself is correctly executed and can retrieve the configuration items via snapctl.

[Michael Vogt (mvo)]

This is because in client/client.go we use os.OpenFile(dirs.SnpadSocket) and on EACCESS we re-try with dirs.SnapSocket. This of course causes some spam in dmesg.