Interface management in the context of snap in a classical Debian install

[Jamie Strandboge]

On Tue, 2017-01-10 at 03:32 +0000, Luther Goh Lu Feng wrote:
> Bumping this up again since I didnt seem to have received a reply. Was my
> question sufficiently clear?
> 

Sorry no one responded sooner.

At this time, snapd on Debian[0] puts all snaps in devmode so there are far
fewer restrictions place on the snap than on systems where confinement is
enforced. On Debian, snaps will be able to access all files in the core snap, a
few bind mounted directories from the system (like /run) and various IPC
mechanisms. As such, your golang web service should be able to access services
provided by debs via network IPC (eg, if influxdb opened a port on the loopback
interface), DBus, abstract UNIX domain sockets, anonymous sockets, and named
sockets if the named socket is in one of the system bind mounted directories
(eg, /run/influxdb).

On systems with full confinement, snaps run in a sandbox[1][2] that is
configured by snappy interfaces[3]. This sandbox controls how the snaps interact
with the system and other snaps. On these systems, your golang web service would
not be able to access services provided by debs by default. Some interfaces are
intended to work on traditional (aka, 'classic') systems so if there is an
interface implemented in snapd for a particular service provided as a deb, then
connecting that interface for the snap would give the snap access to that system
service (eg, network-manager, ofono, etc). There is no interface for influxdb at
the moment, so your snap would not be able to access any of its files or non-
network IPC mechanisms. If influxdb listened on a network port (eg, on
loopback), then your snap would be able to access this port if the 'network'
interface was connected.

[0]https://github.com/snapcore/snapd/wiki/Distributions#debian
[1]http://snapcraft.io/docs/reference/confinement
[2]https://github.com/snapcore/snapd/wiki/Security
[3]https://github.com/snapcore/snapd/wiki/Interfaces

> 
> -- Luther
> 
> 
> 
> On Tuesday, January 3, 2017 4:39 PM, Luther Goh Lu Feng <elfgoh at yahoo.com>
> wrote:
> I am considering the scenario where snap is installed in a classical Debian
> install. I intend to package my golang web service in a snap. The web service
> may have some dependencies that are present in the debian repository, but not
> available as a snap. Examples could be a database like influxdb, or a reverse
> proxy like nginx.
> 
> My question is: how will the snap be interfacing with non snap software in the
> context of interfaces[1]? Is there an example? 
> 
> I understand that it will be more ideal if the dependencies are also snaps,
> but this may not be possible in the near future. Please advise implications
> and other alternative implementations. Thanks.
> 
> 
> -- Luther
> [1] http://snapcraft.io/docs/core/interfaces
> 
-- 
Jamie Strandboge             | http://www.canonical.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20170110/79808c10/attachment.sig>