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.
The .dunner.yaml is not necessarily present in HOME directory. User can initialize dunner in any of his projects which creates a .dunner.yaml file. So permissions we would need are:
Read dunner.yaml file which can be present anywhere in the filesystem, not necessarily in root 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
Let me know if you have any questions on this. For reference, our requirements are similar to GoReleaser tool which also uses classic confinement.
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:
All that isnāt available is ~/.foo/.dunner.yaml. It seems like this would be sufficient? If not, can you explain the use cases for when projects are stored in top level dot directories?
I tried using the home plug with strict confinement and now I can access the use files as expected.
However, I get an error to access Docker as my project(Dunner) is a docker based task runner and needs to have permission to access it, access all containers(private too).
Can you please point me to related plugs I have to use? Dunner internally spins up docker container, runs tasks and aggregates the results based on user configuration.
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.
Did you try running as root/sudo? Your user may not be in the docker group.
Additionally, the docker plug needs to be connected to a slot, such as the docker-daemon slot exposed by the docker snap, so if you try something like:
$ snap connect dunner:docker docker:docker-daemon
Then see if it works (and also make sure your user is in the docker group or is root).
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.