Wine + posix message queues = oops

snapd
1

paging @jdstrand:

I’ve built a wine snap to package command & conquer: red alert, but it’s failing hard with an audit message reporting:

 [13106.693915] audit: type=1326 audit(1527871926.950:2849): auid=1000 uid=1000 gid=1000 ses=2 pid=90497 comm="wineserver" exe="/snap/cncredalert/x1/bin/wineserver" sig=0 arch=40000003 syscall=241 compat=1 ip=0xf7f76059 code=0x50000

which if I’m correct is the syscall mq_unlink from the message queue subsystem?

The snap outputs the following at the moment that audit message is triggered and then hangs (I had to press alt+f2 to get a run dialog from my desktop environment to execute xkill and click anywhere to kill the transparent full-screen chromeless window):

005c:err:seh:setup_exception_record stack overflow 1136 bytes in thread 005c eip 7bc455b6 esp 00230ec0 stack 0x230000-0x231000-0x3300001

I believe that message is actually output by the command & conquer executable rather than wine itself…

The snapcraft.yaml for you to recreate my snap is at https://github.com/diddledan/cncredalert.

2

Note the ‘arch=40000003 syscall=241 compat=1’: ‘compat=1’ is important. So, it isn’t mq_unlink, it is this:

$ scmp_sys_resolver -a x86 241
sched_setaffinity

(snappy-debug would have done this for you). You need to plugs process-control.

3

thanks. I’ll give that a go :slight_smile:

4

That got further, but failed with a similar stack overflow message, and this from snappy-debug:

= Seccomp =
Time: Jun  1 21:06:09
Log: auid=1000 uid=1000 gid=1000 ses=2 pid=21899 comm="wineserver" exe="/snap/cncredalert/x2/bin/wineserver" sig=0 arch=40000003 26(ptrace) compat=1 ip=0xf7fd6059 code=0x50000
Syscall: ptrace

Console output from wine:

003a:err:seh:setup_exception_record stack overflow 1136 bytes in thread 003a eip 7bc455b6 esp 00240ec0 stack 0x240000-0x241000-0x340000
5

I suspect the ptrace is not because it needs it but because it crashed. For debugging only, feel free to add this to /var/lib/snapd/seccomp/bpf/snap.cncredalert.<whatever>.src:

ptrace

Then run:

$ sudo /usr/lib/snapd/snap-seccomp compile /var/lib/snapd/seccomp/bpf/snap.cncredalert.<whatever>.src /var/lib/snapd/seccomp/bpf/snap.cncredalert.<whatever>.bin

Then adjust /var/lib/snapd/apparmor/profiles/snap.cncredalert.<whatever> to have:

ptrace peer="snap.cncredalert.*",

then run:

$ sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.cncredalert.<whatever>
6

still getting seccomp kick in on ptrace with those two amendments:

= Seccomp =
Time: Jun  3 16:05:06
Log: auid=1000 uid=1000 gid=1000 ses=2 pid=21899 comm="wineserver" exe="/snap/cncredalert/x2/bin/wineserver" sig=0 arch=40000003 26(ptrace) compat=1 ip=0xf7fd6059 code=0x50000
Syscall: ptrace
7

Sounds like either you didn’t update and compile the correct seccomp profile or you didn’t restart the application after updating the profile (unlike apparmor, you have to restart your application for it to use the new seccomp policy; I neglected to mention this in my previous post).

8

Just a theory, because it’s still definitely denying the ptrace: is our seccomp implementation taking account of x86 syscalls on an amd64 system? i.e. are we allowing ptrace in i386 binaries in addition to ptrace from amd64 binaries? If we’re not matching both architectures in our allow-deny then that might account for it still being blocked when I’ve specifically added ptrace to the config as you advised above…

9

Yes, on bi-arch systems this happens automatically.