On Fri, 2017-02-10 at 15:34 +0800, James Henstridge wrote:
> 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/1663177FYI, James provided a PR request for this bug (thanks!) and it is committed to master and will be in snapd 2.23. -- Jamie Strandboge | http://www.canonical.com
signature.asc
Description: This is a digitally signed message part
-- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
