Broken application that hasn't any seccomp or AppArmor violation

Hello, I have a problem with my application that works outside SnapCraft containment flawlessly, but as a SnapCraft package something is broken. It’s an app that streams audio and video to the Vonage service using their SDK. The problem is that in snap it doesn’t stream anything at all despite the application seems working correctly and I don’t have an idea why. This is syslog output related to the application run:

Oct 18 03:48:39 raspberrypi systemd[1]: Started snap.main.main.4dc5b8bb-36b0-4638-a73c-cecb0ad0f8bd.scope.
Oct 18 03:48:40 raspberrypi kernel: [  771.504037] audit: type=1326 audit(1666082920.209:3): auid=1000 uid=0 gid=0 ses=1 pid=2131 comm="main" exe="/snap/main/x7/bin/main" sig=0 arch=40000028 syscall=97 compat=0 ip=0xb6138948 code=0x7ffc0000
Oct 18 03:49:07 raspberrypi systemd[1]: snap.main.main.4dc5b8bb-36b0-4638-a73c-cecb0ad0f8bd.scope: Succeeded.
Oct 18 03:49:07 raspberrypi systemd[1]: snap.main.main.4dc5b8bb-36b0-4638-a73c-cecb0ad0f8bd.scope: Consumed 33.955s CPU time.

There is a line that says that there’s seccomp violation, but I changed and recompiled that seccomp profile and the problem persist despite snappy-debug is not complaining at any violation, so it’s seems that it isn’t an issue.

This is my snapcraft.yaml:

name: main
version: '1.0'
summary: streaming app
description: our streaming app
confinement: strict
grade: stable
base: core18

parts:
  alsa-mixin:
    plugin: nil
    source: https://github.com/diddledan/snapcraft-alsa.git
    override-pull: |
      cat > alsa.conf <<EOF
      pcm.!default {
        type pulse
        fallback "sysdefault"
        hint {
          show on
          description "Default ALSA Output (currently PulseAudio Sound Server)"
        }
      }
      ctl.!default {
        type pulse
        fallback "sysdefault"
      }
      EOF
    override-build: |
      install -m644 -D -t $SNAPCRAFT_PART_INSTALL/etc alsa.conf
    build-packages:
      - libasound2-dev
    stage-packages:
      - libasound2
      - libasound2-plugins

  libraries:
    plugin: dump
    source: lib/tokbox/lib/.
    organize:
      libopentok.so: lib/libopentok.so
    stage-packages:
      - libc++1
      - libc++abi1

  stream:
    plugin: cmake
    source: .
    build-packages:
      - build-essential
      - libc++-dev
      - libc++abi-dev
      - libuv1-dev
      - libunwind-dev
      - libasound2-dev
      - libsdl2-dev
    stage-packages:
      - libc++1
      - libc++abi1
      - libunwind8
      - libuv1
      - libasound2
      - libasound2-plugins
      - libsdl2-2.0-0
    after:
      - alsa-mixin

layout:
  /usr/lib/$SNAPCRAFT_ARCH_TRIPLET/alsa-lib:
    bind: $SNAP/usr/lib/$SNAPCRAFT_ARCH_TRIPLET/alsa-lib
  /usr/share/alsa:
    bind: $SNAP/usr/share/alsa

apps:
  main:
    command: bin/main
    plugs:
      - alsa
      - audio-record
      - audio-playback
      - network
      - network-bind
    environment:
      ALSA_CONFIG_PATH: /snap/$SNAPCRAFT_PROJECT_NAME/current/usr/share/alsa/alsa.conf

My question is:

  1. How I can debug where is the problem with my snap package? I don’t have any AppArmor or seccomp violation. Running in devmode and other confinement’s modes makes no difference. I don’t know if it’s an issue with my application code or with SnapCraft package configuration.
  2. How ALSA or sound configuration in general can differ from typical host system configuration?

install the snappy-debug snap and run it alongside when (re)starting your snap. it should give suggestions what interfaces to use with your snap …

It doesn’t recommending anything, so I assume I have all interfaces that are needed.

syscall 97 is unshare (you can find that out by running snappy-debug.scmp-sys-resolver 97 on the hardware you see the error (note syscall numbers vary by architecture so this is important)

grepping through:

shows that the network-control interface actually allows this syscall … (along with browser-support and some other super privileged interfaces). so try adding and connecting network-control to your app and see if that helps.

Yes, but I’m using ARM, so syscall 97 means setpriority in this architecture. That’s what scmp-sys-resolver returns. What can I do now?

hmm, i ran it on an arm64 system here to find the syscall name …

if it should really be setpriority this usually does not make your app fail at all and is harmless (and beyond that it is also provided by audio-playback which your app seems to have already (is it connected ?))

Yes, it’s connected.

so are you running armhf that you got a different name for the syscall number ?

Yes, it’s armhf architecture.

ah, that explains it … well, as i said before, setpriority is harmless and should not stop your app from working, there must be something wrong with your app then …