I believe access to shared memory is namespaced. If you have access to the source you could modify it to access the correctly namespaced paths (specifically snaps only have access to /dev/shm/snap.<snapname>.*).
I can’t patch the source code for libjack because the server will be running outside the snap environment, and it expects the client to use /dev/shm/jack-1000/default/jack_0
Here, 1000 is my user id, and jack_0 is, I believer, the first server.
I will try using snapcraft-preload, even though I don’t understand what it does
But that won’t solve my problem because the endpoint to connect to the serveur is fixed. I guess it is the same thing with all snaps that need to connect to a server outside of the confinement.
I’ve been playing around - and googling a lot ! - and my conclusion is that there is absolutely no way - in strict mode - to make a snaped program (a jack client in my case) talk to a host serveur (jackd) using shared memory, because :
snaps can only access /dev/shm/snap.<snap-name> ;
jackd can’t use that path because it can’t know in advance what snaps are going to connect to it.
Am I correct ?
Is this ever going to change ?
I guess asking users to install the snap using --devmode defeats the strict confinement…
well, pulseaudio (and other interfaces) surely allow it in a limited way. what you’d need here would be a similar interface to the pulse one i guess (@jdstrand may correct me though) to grant your app access to the host daemon … i think some time between 15.04 and 16.04 such a jackd interface was even discussed (when we still had a mailing list, before the forum existed to discuss snap matters).
@ogra is correct. Since jackd is running unconfined as a non-snap on the host and providing a client endpoint somewhere, a new ‘jack’ interface would need to be created (first step would be an implied interface on classic only, but later also supporting a slot implementation for a jackd snap).
If you are so inclined, you might create a PR against snapd, basing your work on the openvswitch interface in interfaces/builtin/openvswitch.go (and openvswitch_test.go). Otherwise, I can try to incorporate this in some 2.39 policy updates work I have planned. Do you have a simple snap that demonstrates the problem as well as instruction on how to configure jackd for testing?
I’ve already started looking at making an interface for jackd. I will gladly submit a pull request when I’m done. In the meantime, I will probably need help ! Should I start a new thread when I encounter a problem, or keep this one going, for reference ?
If the questions have to do with the technical details of how to implement the interface, just submit the PR and people can help there. If you are running into really strange design issues, then here is fine.
$ snap run jack-client-test
Jack client successfully connected !
Server's sample rate is 44100
Server's CPU load is 0.235450
Disconnected from server
Pull Request 6695 but it won’t pass because I haven’t signed the CLA. I have downloaded the PDF but I have no idea what to do with it ^^ I hope I’ll figure it out soon .