We are working on releasing the next version of Dunner on the snap store, and we already have a working test snap, but we deemed that the classic confinement is needed by our software. We’ll need to access the config file, i.e dunner task file to read and execute dunner tasks. We tried it with strict confinement, but that gives an error as: open .dunner.yaml: permission denied
For this reason, we would like to request permission to use the classic confinement for the upcoming dunner snap package.
A lot of software is capable of adjusting its config file, but by far most users just use the default. Snaps are designed to be isolated from each other, and to various extents depending on interface connections, the host filesystem. Access to a dot file in home is typically not a justification for classic confinement.
In the specific case of ~/.dunner.yaml, it still isn’t clear to me why this is required. HOME is set to ~/snap/dunner/<revision> such that the you can write to anywhere in $HOME (eg, $HOME/.dunner.yaml (which is ~/snap/dunner//.dunner.yaml), $HOME/.some-other-dunner.yaml (which is ~/snap/dunner//.some-other-dunner.yaml), etc).
For cases when HOME is not sufficient, there is the personal-files interface. The interface is intended to be read-only for importing an existing configuration from a non-snap install, but also supports write. Please note that there is a review process for use of the personal-files interface (specifying ‘read’ is typically fine so long as it is clear that the application is the owner of the file (which for Dunner, ~/.dunner.yaml is clear) but use of write typically requires justification in terms of compatibility and robustness of the snap to not break non-snap install and vice versa.
All that said, the initial request only discussed ~/.dunner.yaml, where, as stated above, there are various means to address this with a strict mode snap. However, you later said that your requirements are similar to goreleaser which has many other reasons to be classic. Assuming that your snap could be adjusted to handle ~/.dunner.yaml in strict mode, are you saying there are other reasons why this must be classic? If so, please describe typical use cases.
In my request, it is mentioned as .dunner.yaml file, but its not specified that it is in HOME directory. Dunner is a command-line based task runner reading the configuration in mentioned task file. This can be created in any project directory by user. So dunner needs to access this file in working directory of user.
When I said it’s similar to Goreleaser, goreleaser uses a config file specific to each project. Similarly, Dunner reads the tasks configured in .dunner.yaml file which can be present in any location. We want to read it from working directory of user.
So permissions we would need are:
Read dunner.yaml file which can be present anywhere in the filesystem, not necessarily in home dir.
The filename can also be customized, user has an option to name dunner.yaml differently by passing a custom flag.
Write permission to initialize a config file in the new project.
Read permission for .env file in working directory of user
Thanks for the extra information. Typically for the access you described plugs: [ home, removeable-media ] in a strict mode snap is sufficient, since projects you described (AIUI) are not going to live in toplevel dot directories. Eg, with using plugs like the above, people can put .dunner.yaml and .env files in:
Your snap needs to plugs ‘docker’. Note that use of this interface requires approval to be distributed in the public store because it effectively grants device ownership to the snap. Please try plugging this interface and manually connecting it, if that works, we can convert this to a request for using the docker interface.
@jdstrand In order to be able to access Docker, i used the docker plug as below:
plugs: ["home", "docker", "docker-support"]
home plug is to be able to access files, as discussed in previous message. It works. docker plug to enable permission to access docker. My application uses docker client to spin docker container and run tasks. Even with this plug, I get this error:
Its permission denied error when trying to connect to docker deamon. Can you let me know if I have missed any step? What do you mean by manually connecting to interface? I didn’t get it.
The Dunner description says ‘A Docker based task runner tool’ and so it seems appropriate that this snap be allowed to use the docker interface.
+1 to allow installation when plugging the ‘docker’ interface. @reviewers - can some of you also vote on this
As for auto-connection, I’m uncomfortable allowing auto-connection because the docker interface provides device ownership to the snap. Since your snap is meant to integrate with an existing docker install, the dunner snap would necessarily need to provide steps beyond ‘snap install dunner’, therefore it seems reasonable that the steps become:
install docker with…
install dunner with snap install dunner
allow dunner to use docker with snap connect dunner:docker
(or similar). Furthermore, the dunner snap could quickly see if it could connect to the docker socket and guide the user (eg, “Could not connect to docker. Did you perform ‘snap connect dunner:docker’ as root?”). @reviewers - can some of you vote separately for auto-connection?
Note that you can’t run snap connect dunner:docker without a slot to connect it to. It needs to connect to the slot from the docker snap, there is no other snap that provides the necessary slot, and it is not provided by the core/snapd snaps.