Request use of docker interface [Was: Classic confinement request: Dunner]

store-requests
#1

Hi team,

Dunner is an open source task runner tool based on Docker. It allows defining tasks and steps of the tasks in .dunner.yaml file and then run these steps with dunner do task name. Here is the GitHub page of our tool: https://github.com/leopardslab/dunner
Link to dunner snap: https://dashboard.snapcraft.io/snaps/dunner/

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.

Thanks

1 Like
Z1-edgert: Request use of docker interface
Different behavior on Debian Buster and Ubuntu 18.04 LTS
#2

Classic is not necessary if all you want is access to ~/dunner.yaml.

Please check out the personal files interface, it should help in this case.

  • Daniel
#3

@roadmr, Thanks for the response.

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.

– Apoorva

1 Like
#4

@roadmr Please let me know if you need any other info to approve this request.

Thanks

#5

@reviewers Can someone help with approving this request? We are waiting on this.

Thanks
– Apoorva

#6

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.

#7

@jdstrand Thanks for the response.

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

Please let me know if this is not clear enough.

#8

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:

  • ~/project1/.dunner.yaml
  • ~/code/project2/.dunner.yaml
  • /media/$user/$dev/external-code/project3/.dunner.yaml
  • …

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?

[RESOLVED] - Sctl didn't need personal-files
#9

@apoorvam6 - your response is required to proceed with the request.

#10

I don’t think we would need to use top-level dot directories. I’ll try out the suggestion on using plugs with home dir and update on this.

Thanks for it.

#11

Thanks. I’m going to remove this from our review queue for now. Please feel free to respond back here as needed.

#12

Hi @jdstrand, here is an update.

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).

snap_error
snap_error1522×66 22.5 KB

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.

Thanks!

#13

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.

#14

@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.

Thanks

#15

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).

You should not be using docker-support at all.

#16

I tried connecting manually to docker interface and it works with dunner.

Please convert this to a request for connecting to docker interface.

#17

@jdstrand / @ijohnson Please convert this request to use docker interface. If you need any info, let me know.

#18

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:

  1. install docker with…
  2. install dunner with snap install dunner
  3. 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?

#19

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.

#20

We love to give our users the seamless experience like other Snaps where they can simply install Dunner using snap install dunner.