I took a look at your docker-app snap and wanted to mention that it is a novel approach to have the docker snap export a content interface that has the tools that an app snap could use to drive docker for application containers delivered as snaps. I do want to mention that in looking at the docker app snap, you are having to plugs both docker-support and docker which means:
- because of
docker-support, the app snap will need a snap declaration to install from the store (because thedocker-supportinterface is super-privileged) - because of
docker, the app snap will need to have the interface connected manually
Because of docker’s capabilities (docker-support is meant for dockerd which requires extensive permissions to run) and because of docker’s design (access to the dockerd socket gives full access to all of docker’s capabilities), both interfaces allow trivial confinement breakout and are intended only for use with trusted snaps from trusted publishers since when plugging either interface, you have in practice granted the app snap device ownership. As such, I strongly advise against using this mechanism with untrusted docker app snaps. For trusted snaps for a brand store, this may be interesting (since brand stores can issue snap declarations allowing these connections). For the public store, developers will be frustrated trying to deliver application containers in this manner since they’ll bump into the base declaration’s policy.
If delivering application containers via snaps in a general-purpose, developer-friendly and secure manner in the public store is important, I suggest working with docker upstream (eg, using a proxy, putting ACLs on the docker socket APIs, introducing another socket with secure APIs, etc).