Classic confinement for IVPN software (consultation)

Hello,

I am going to prepare and publish a snap package(-s) for our software (https://www.ivpn.net/apps). But, before doing that, I want to consult about some questions.

The software I want to publish is an open-source VPN client (https://github.com/ivpn/desktop-app).

It is split into two general parts:

  1. a daemon, which works as a system service with privileged user rights (and also a small CLI tool). The privileged environment is required for daemon because of various reasons: to be able to establish a VPN connection, to control DNS configuration, to control firewall rules (iptables), to monitor changes in network interfaces… etc.
  2. a UI which is an Electron application that is communicating with daemon over the localhost socket interface.

Here are the questions I want to consult with you:

  1. Due to the reasons described above, I see the only way to make ‘daemon’ work is to use ‘Classic’ confinement for the snap. Is there any chance for such a package to be approved for publishing on the Snapcraft store?
  2. It seems, in general, that UI can work in ‘Strict’ snap confinement. So I assume that the UI can be packed into a separate snap with strict confinement. The only problem which I have to solve: the UI needs to have read access to a single file in the filesystem (the file were created by daemon). This file is common for all users in a system, so saving it in the home folder is not a solution. What is the best way to solve it? Additionally, I want to avoid any manual work from the user side. So, I do not want users to connect snap interfaces manually.
  3. Can the UI be packed together with a daemon into one snap (using Classic confinement)? I mean, can such a snap be approved for publishing on the Snapcraft store?

the first two should be covered by the network-control and/or network-manager interface …

for access to firewall settings there is the firewall-control interface.

to watch the network interfaces you have the network-observe interface …

… and to provide a localhost TCP socket for the client, the network-bind interface should be enough …

there should be no need to make anything classic …

Regarding questions 2 and 3, you can ship the daemon and client/GUI in the same snap. If you ship them in the same snap, they’d be able to access the same $SNAP_COMMON directory, which is where you’d usually place shared configuration for all users.

You could also ship them both as separate snap, and then allow one to access some of the content of the other via content-sharing, I believe content-sharing doesn’t require any store approval as long as the publisher is identical for both.

Though as Ogra says above, you can probably run the daemon portion as a strict snap, in which case it likely makes more sense to just bundle daemon and client together.

@ogra @James-Carroll Thank you! I will try to play with your suggestions.