Snapping a jack client


#1

Hello,

I’m trying to snap a jack client, that is supposed to connect to jackd - the server - running on the host.

A sample test case is available here.

It doesn’t seem to work because the client inside the snap wants to connect to the server using shared memory :

$ snap run --strace jack-client-test
......
[pid 23471] socket(AF_UNIX, SOCK_STREAM, 0) = 3
[pid 23471] getuid()                    = 1000
[pid 23471] connect(3, {sa_family=AF_UNIX, sun_path="/dev/shm/jack-1000/default/jack_0"}, 110) = -1 ENOENT (No such file or directory)
[pid 23471] close(3)                    = 0
[pid 23471] write(2, "connect(2) call to /dev/shm/jack"..., 92connect(2) call to /dev/shm/jack-1000/default/jack_0 failed (err=No such file or directory)
) = 92
[pid 23471] write(2, "attempt to connect to server fai"..., 36attempt to connect to server failed
) = 36
......

Is there something I can do to make it work ? Is it even possible to do ?

I’m available for any info or help you might need from me !

Thanks.


#2

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>.*).

If you don’t you might look at: https://github.com/sergiusens/snapcraft-preload. I believe it should dynamically rewrite syscalls to /dev/shm to their properly namespaced paths.


#3

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 :slight_smile:


#4

So, snapcraft-preload apparently did what it is supposed to do (although I’m not sure about all those \0) :

...
[pid  1977] connect(3, {sa_family=AF_UNSPEC, sa_data="/dev/shm/snap.jack-client-test.jack-1000/default/jack_0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 110) = -1 EINVAL (Invalid argument)
...

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.


#5

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 :

  1. snaps can only access /dev/shm/snap.<snap-name> ;
  2. 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…


#6

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).


#7

@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?


#8

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 ?


#9

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.

Thanks for taking this up! :slight_smile:


#10

Hey, look at that !

$ 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

:slight_smile:

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 .


#11

@mvo - can you help @yannick-mauray with the CLA for https://github.com/snapcore/snapd/pull/6695 ?


#12

Hi ! Now that 19.04 has been released, is there any chance PR #6695 could be reviewed - and hopefully merged :slight_smile: ?

I’d really like to share my app with friends so they can test it, but I don’t want to build a deb !

Thanks.