I was snapping up a D-Bus service I'm responsible for, and had it
crash with a "Bad System Call" error, and the following in the dmesg
output:
[2054724.068967] audit: type=1326 audit(1486700103.228:2687):
auid=1000 uid=1000 gid=1000 ses=2 pid=29311 comm="mediascanner-se"
exe="/snap/mediascanner2/x1/bin/mediascanner-service-2.0" sig=31
arch=c000003e syscall=45 compat=0 ip=0x7f28d037866d code=0x0
This appears to be the recvfrom system call. The snap was configured
with a slot using the generic "dbus" interface, but not the "network"
plug. If I add "network", the problem goes away.
Looking at the seccomp filters for "dbus" interface definition in
snapd it allows recvmsg and sendmsg, but the D-Bus library this code
uses (GLib's GDBus) uses recvfrom() (at least it does while
initialising the connection).
My first thought was that these extra system calls to the dbus
interface's seccomp filter. But then I took another look at what
calls were enabled for the base policy, which showed socket(),
connect(), {get,set}sockopt, and a few others. The only thing
preventing the default policy from creating IP sockets is the AppArmor
policy.
Given that the default policy nominally allows communication via unix
domain sockets within a snap, I wonder if it would make sense to move
the other socket related syscalls from the network interface to the
default?
I've created the following bug report to help track this problem:
https://bugs.launchpad.net/snappy/+bug/1663177
James.
--
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/snapcraft
