Syncplay is an open source software that synchronises the position and play state of multiple media players so that the viewers can watch the same thing at the same time. See https://syncplay.pl and https://github.com/Syncplay/syncplay for further information.
We are working on releasing the next version of Syncplay on the snap store, and we already have a working test snap, but we deemed that the classic confinement is needed by our software. Specifically, we need to interact with media player binaries installed in the user system (e.g mpv or vlc, typically located in /usr/bin/).
For this reason, we would like to request a permission to use the classic confinement for the upcoming syncplay snap.
Looking at the website it appears there is some sort of network coordinate where syncplay will drive various playback options via the command line of various media players. I don’t see a path forward for this application wrt strict confinement unless we required use of mpris or some other protocol. Does syncplay support driving applications via mpris?
That said, the idea of having a network server that takes input from over the internet to run arbitrary commands is pretty scary and something that would benefit greatly from strict confinement. @pedronis - this is a new class of classic application, can you weigh in?
Thank you for considering classic confinement for Syncplay, which is an open source project with over 2,000 weekly active users that has been actively maintained and developed over the past seven years.
Syncplay does not take input from over the internet to run arbitrary commands.
Currently playing file if shared playlists are enabled (only opens files located in user-specified media directories or on whitelisted websites)
The following aspects of the media player are affected, but not controlled, by the server:
OSD / On-screen display (for the display of messages).
Playback rate (for slowdown due to time difference).
In answer to your query, Syncplay was not designed to be used with mpris. We have not limited our supported media players (VLC, mpv, MPC-HC, MPC-Be) or supported operating systems (Windows, Linux, *BSD, macOS) to those which work with mpris. Furthermore, in terms of features we have worked with the developers of those media players to make the most of the functionality of each media player to provide the best user experience
As such, I hope that Syncplay can be granted permission for classic confinement as it is necessary for the operation of the software.
I meant arbitrary in terms of what is allowed by the confinement and the system. Syncplay obviously isn’t designed for that specifically, but classic confinement grants this to the snap so a flaw in syncplay would mean there is nothing to stop this.
We use different ways to interact with each media player. On Linux, we support mpv and VLC. mpv is controlled primarily via its CLI. VLC is controlled using a custom LUA script executed by the player. In both cases, we need to run an instance of the media player in a python-controlled subprocess, using a lot of custom CLI options, and redirect stdout/stderr to our software. This is only feasible if Syncplay has access to the media player binaries.
mpv provides an alternative control method based on JSON IPC, which uses a socket to pipe commands and data. However, at this moment Syncplay does not support at all this IPC, so we would have to rewrite our control system for mpv from the ground up. In addition, without access to the mpv binary, the user would have to manually run the player outside the snap, supplying the CLI arguments needed (including our configuration and the socket used for the IPC), then pass all this to the snap instance of Syncplay. While technically possible, this would make running Syncplay quite cumbersome. Furthermore, we provide a chat/notification system on mpv, based on a custom LUA script. To the best of our knowledge, these advanced features would not have been possible using the JSON IPC system.
VLC provides some LUA-based alternative protocols (e.g. http or telnet), but neither provides the control mechanism nor the information that Syncplay needs. Hence, we had to create our custom LUA script with support from the VLC team. Additionally, we need to run VLC from Syncplay to specify the loopback port and prevent issues when more than one instance of Syncplay is being run at a time.
Data exchanged between the media player and Syncplay use a different protocol from the one used to exchange data between Syncplay client and remote server. The latter protocol runs on TCP, is JSON-based, and is documented here.
There is a stable vlc snap, I wonder if it would be worth exploring/experiementing if that could expose a content plug that would allow to use that, instead of granting classic to access any system vlc (but much more too). @jdstrand any thoughts from your side on this?
@jdstrand ping, it sounded like you had thoughts about what is possible now and what could be possible in the future that are relevant to deciding the way forward here
As discussed at the sprint, today this snap cannot operate under strict confinement. Going forward, it might be possible that through snap-coordination, this snap could be made strict. Specifically:
snapd implements the concept of snaps launching other snaps via userd or similar. This is needed for a desktop shell to launch arbitrary applications. I envision this potentially working similar to xdg-open in that the snap calls a binary that communicates with userd (or similar) over dbus, telling it which desktop file to launch and then userd launches the application. To accommodate something like syncplay, there would be some mechanism to specify which applications syncplay would be allowed to launch (eg, vlc and mpv), and userd would mediate this access.
the snaps to be controlled (eg, vlc and mpv) expose a content slot that allows the controller (ie syncplay) to access the resources needed to control it. In the case of mpv, that would be sharing a binary (likely wrapped by a script to set things like LD_LIBRARY_PATH) and in the case of vlc, a writable area to put the LUA script
There is still the concern that because syncplay takes commands over the network and converts them to whatever is needed to control vlc and mpv, its users could be exposed to flaws. The requester stated that it is not designed to “take input from over the internet to run arbitrary commands” so it potentially ok to allow classic temporarily until strict is possible, on the condition that future revisions of the syncplay snap don’t gain more functionality in the realm of taking “input from over the internet to run arbitrary commands”.
@pedronis - I think that summarizes our conversation from the sprint.
Thanks for your work on this. We think our users would be really happy for having a Syncplay Snap available. Hence, we would really appreciate if classic confinement could be given to Syncplay as an interim measure, until Snap allows for applications to launch and interact with specific other Snap applications. We are happy to confirm that Syncplay will not gain functionality in the realm of taking “input from over the internet to run arbitrary commands” in the foreseeable future.
Based on conversations with @pedronis from the sprint, the requirements are understood, a long term path for removing classic is documented and upstream understands that classic is temporary until such time as something better can be done. In addition, upstream has no plans to expand the functionality in the ways that concerned @pedronis and I.
Granting use of classic. This is now live. Your next upload should pass automated review. If you want to use revision 1, please request a manual review in the store and I can re-run the review.
