Issues with dlopen() on loading VST/CLAP plugins in strict mode

snapcraft
1

Hi everyone,

I’m developing an audio app in strict mode which loads audio plugins, such as VST and CLAP, that are located in hidden folders in the home directory, like ~/.vst and ~/.clap. I have already configured the “personal-files” plug in my snapcraft.yaml to allow access to these directories and I also added the “home” connection to ensure access to files in the home directory.

However, when the app tries to use dlopen() to load plugins from these directories, the operation fails blocked by AppArmor. Here is the log:

apparmor=“DENIED” operation=“file_mmap” class=“file” profile=“snap.myapp.myapp” name=“/home/user/.vst3/lsp-plugins.vst3/Contents/x86_64-linux/lsp-plugins.so” pid=46811 comm=“vstscan” requested_mask=“m” denied_mask=“m” fsuid=1000 ouid=1000

I want to specify that the app has two executables, the main one launches the secondary one “vstscan” which performs the plug-ins scan.

Here are my questions:

  1. Is there a way to allow a Snap in strict mode to load plugins from ~/.vst or ~/.clap without running into security or confinement issues?
  2. Are there any alternatives or modifications I can make to my snapcraft.yaml to allow the dynamic loading of these files?
  3. If this isn’t possible, would it be advisable to consider classic confinement for an app like this?

Thanks for your help!

2

Can you confirm that you’ve run sudo snap connect mysnap:plugname as appropriate for your personal files interface? Simply defining it won’t connect it, it needs to be done manually (or overridden via the store when submitted for releases, the store will also demand a review even if left disconnected by default).

I’m unsure if mmap could be interfering here, but it’s common for people to forget the connect isn’t always automatic. That said, I don’t think mmap and normal reads are functionally much different from a sandboxing POV, it’s not the intention of the sandbox to deny efficiency, so if it is specifically mmap causing issues, it might simply need adding to the interface for the benefit of other snap users too.

Classic would be unlikely to be given for something like this as it’s not always unreasonable to ask users to change their user flow to adapt to snap requirements, such as writing config files in alternate paths & etc. That said, it’s also then likely classic isn’t needed at all for this, as it sounds like either the personal files interface simply isn’t being used as it’s unconnected, generally we’d rather people push strict as far as possible before going to classic and for now I’d say there’s still options worth exploring.

Classic generally has specific criteria to be accepted, and simply being difficult isn’t treated by itself as valid, see here:

3

James, thanks for your reply.

Here is the output of the snap connections myapp command:

...
`personal-files           myapp:vst-clap-personal        :personal-files  manual`
...

Below is an excerpt from my .yaml file:

apps:
  myapp:
    ...
    plugs: [home, vst-clap-personal, removable-media, network-bind, network, alsa, opengl, x11, wayland, desktop, desktop-legacy, audio-playback, audio-record]

...

plugs:
  vst-clap-personal:
    interface: personal-files
    read:
      - $HOME/.vst
      - $HOME/.clap 
      - $HOME/.vst3
    write:
      - $HOME/.vst             
      - $HOME/.clap     
      - $HOME/.vst3

I can confirm that the vst-clap-personal interface is correctly connected because, when I run the command snap run --shell myapp, I can list the contents of those folders (.vst, .vst3, .clap). The same operation rightly fails with a ‘permission denied’ error when the plug is not connected

Any ideas?