Something has changed in the Snapcraft sandbox that has broken my applications

snapd
1

When I execute the binary outside of the Sandbox they function just fine, but once executed via the sandbox they now exhibit some very strange problems;

  1. No sound (which could be explained by some package or permission requirements being added to the snapcraft.yaml that were not specifically required prior)

  2. UI is completely non-responsive (this is even stranger, how could the program execution flow be broken like this)

Anyone have any idea what has happened? It’s concerning that an update to the sandbox could potentially break existing applications listed on snap without the developer being aware of the breakage unless they regularly test said applications on some weekly or daily interval.

2

I don’t know about responsiveness of the UI, but I can at least get you audio support - currently your snaps do not specify the audio-playback interface in your apps.<appname>.plugs entry in snapcraft.yaml. This interface is not requested by the gnome-3-34 extension, so you need to add it manually:

apps:
  borger0:
    extensions: [gnome-3-34]
    command: borger0
    plugs:
    - audio-playback
1 Like
3

Unsure if related, but I had to add this to the command chain in my mpg123 snap to have sound output in jammy with X11 (wayland worked fine):

4

That script isn’t needed if you’re using a desktop extension, like gnome-3-34 as is used here.

1 Like
5

Ah yes, that’s true, I see that the same content is available there.

6

Just to check in I added - audio-playback to my plugs and that seems to have fixed it, whatever issue I was having with the sandbox breaking parts of the UI seems to be fixed now.

The confusion was caused because the audo was working without the - audio-playback plug being defined in the snapcraft.yaml prior to the creation of this thread and tbh I find the snapcraft.yaml stuff pretty confusing.

However I am happy now that my most downloaded snap (Borger3) with 250+ installs now actually works as intended lol!

1 Like
7

Actually I still have one small problem that I remember now having originally when the sound did work - when the application opens; all the audio on the computer becomes degraded slightly, this includes audio from other applications. This only happens when executed via the sandbox.

It does grow tiring having to battle with the Snapcraft sandbox, it’s not easy to setup, it makes it significantly difficult to release software on Snapcraft.

I originally reported this sound issue over a year ago here:

and another issue which this time is caused by the sandbox is that when the SDL application is launched via the sandbox it makes all other audio playing from other applications sound really choppy unless I trigger SDL_PauseAudio() to pause audio playback in the sandboxed application.

It would not be so bad if Snapcraft is able to provide the support level required to solve many of these issues caused by the sandbox, but clearly this is not a level of support Snapcraft is actually capable of providing.

Not only this but providing more documentation for a complicated and confusing system doesn’t make it better. The system is not good, it’s not going to help propel Snapcraft, it just hampers it and leaves it open to being replaced by a competitor that can do it better.

I’m not here to rip Snapcraft to pieces, but there are a significant number of issues that make releasing software on Snapcraft significantly harder than it needs to be. I could list many reasonable reasons, but I don’t feel I need to because they’re all so glaringly obvious.

8

I agree releasing software using snapcraft is not easy, but I do not think it is really harder to set up than other options. Sandboxing an application sucks (because out of the box nothing works and you usually you have to fix a lot of small steps breaking functionality), especially if you are unfamiliar with the sandboxing tool or sandboxing in general. The most effective way to approach sandboxing is often going through the complete list of possible plugs/permissions and see what you expect is necessary and what is not. What you describe here is also the pain of working against a moving target (new core/release -> new set of permissions etc). I think snap/snapcraft has still to evolve for a while (e.g. the way the firefox snap is doing updates is an ongoing topic with each iteration fixing the big problems of the iteration before; i do not expect it to be completely fixed by the next iteration), so expect more of those pains when you upgrade to a newer version.

Note that without the security given by the sandboxing feature, I would probably not use snaps on my systems. Our project is a game; gamers would traditionally not care about sandboxing the games they install. So I recognize snap would be a valuable distribution mechanism (because dependencies included) even without the sandbox. But i personally would not install something like my game without being able to restrict it.

so… i think i am rambling… what i wanted to say: having to set up the sandbox gives pain, but it is worth it for your users (IMHO)