Traefik system-files

store-requests
#1

Hello.

I’m trying to publish the Traefik snap and It would be convenient to access /var/run/docker.sock and /run/docker.sock so it can access to a non snap Docker installation. Also /etc/traefik, where config files are usually stored.

Thanks in advance.

#2

The docker interface should provide access to the docker.sock socket. So you should plugs: [ docker ] for that. That would then leave /etc/traefik - are you requesting read or write (which implies read) access for this?

Either way, since this snap is the clear owner of such a path on the host system, +1 from me for read or write access to a system-files interface named etc-traefik to the path /etc/traefik.

#3

Oh one other question - does the snap function without access to the docker socket? The answer to this helps us to decide whether auto-connect to the docker interface is appropriate or not.

#4

The problem with the docker interface is that it is only available if Docker is installed as snap. When Docker is installed for example as deb, there is no interface provider. It can run without Docker, it’s only a configuration provider.

Traefik uses 2 config files as read only (dynamic & static conf), but is also typical to store here the file acme.json, where automatic certs are stored, so write access could be convinient.

#5

Oh apologies, I had thought the docker interface might be implicit on classic systems… I wonder if it would make sense to update the docker interface in snapd so that it could be implicit on classic systems when the docker socket is already present - something like:

diff --git a/interfaces/builtin/docker.go b/interfaces/builtin/docker.go
index 07ba6705b2..0fc07b8e57 100644
--- a/interfaces/builtin/docker.go
+++ b/interfaces/builtin/docker.go
@@ -19,6 +19,8 @@
 
 package builtin
 
+import "github.com/snapcore/snapd/osutil"
+
 const dockerSummary = `allows access to Docker socket`
 
 const dockerBaseDeclarationSlots = `
@@ -51,5 +53,6 @@ func init() {
 		baseDeclarationSlots:  dockerBaseDeclarationSlots,
 		connectedPlugAppArmor: dockerConnectedPlugAppArmor,
 		connectedPlugSecComp:  dockerConnectedPlugSecComp,
+		implicitOnClassic:     osutil.FileExists("/var/run/docker.sock") || osutil.FileExists("/run/docker.sock"),
 	})
 }

(but then I expect this would get tripped up if a docker snap was installed since it would be providing this socket at the same path - so it might need more extensive checks…)

I am not aware of other snaps (that plug docker) wanting / needing this access so I am surprised we haven’t encountered this kind of request before (ie. for a snap needing access to the docker socket of a non-snapped docker). How common do you think this use-case is? Would most users just use the docker snap instead?

#6

I think it won’t be very common, Traefik is also distrubuted as a Docker image and most users will use this install method.

It would also be possible to configure Docker to listen in localhost or to make a link to the docker.sock in a folder where the snap have permissions (I don’t know if this works). But my intention was to make this snap fully featured.

#7

Some time ago this was discussed here in the forum, and even though a PR was created to add this support, it was closed since it seems it was not properly fixing the issue. I did not find any further updates, maybe @pedronis has more context?

Is this a case you expect? Because I see the snap is only setting read access. In the meantime, I am +1 as well for auto-connect system-files with read access to /etc/traefik to traefik since the snap is the clear owner of such directory. We can update it to allow write access if needed. This is now live.

@ed10vi: could you please rename the iface reference to be etc-traefik instead of config to better represent the access being granted to this snap?

Thanks!

#8

Yes (for example when migrating from other install type), but as this path is configurable it is not mandatory. Only read access is because it is the first place where traefik looks for static config and it crashes if it doesn’t have read permissions. Users could always use SNAP_COMMON or SNAP_DATA to store this files.

Yes, of course.

#9

That kind of change seems fragile because the implicit slot could go away between snapd restarts.

In the case where we have optional implicit slots so far the checks has been on the presence of the software and not whether is running or not.

Doing this even more generally so far has been blocked on the issue of what to do in terms of (auto)connections if both the snap and the host package are present.

One issue is that in the end the slots (implicit and on the snap) end up representing the same socket. If I’m recollecting correctly.