Request for "classic" confinement for package Wilfred

store-requests
22

Any updates on this?

23

@prytz I have read back on this thread but I am finding it hard to understand the exact reasons why classic confinement is required - could you please summarise so that a determination can be made as to whether this is appropriate?

24

There are two reasons that I can think of. My application relies on having access to the Docker socket on the host machine. I want it to work regardless if the user has installed the docker snap or if they have installed it separately. That would not be possible with strict. The other reason is that the user is able to choose which path Wilfred is going to store server data on. This path should be outside the snap confinement (which is also why I would like snap to have on-demand authorization to use specific system resources).

Hope that makes it clear, let me know if there is anything else.

25

To clarify further: It could work with the snap being confined to the user’s home directory, the real gamebreaker is not being able to access a Docker socket that is not installed via snap.

26

Any updates regarding this?

27

Thanks for the additional information. IME this is a bug in the docker interface. Currently it is not marked as an implicitOnClassic slot, but it should be since, like our libvirt interface. I’ve taken a todo to implement this for snapd 2.44 (the next release). In the meantime, please use devmode until 2.44, then strict mode should work for you.

28

I see. Would I not have to request authorization to use the Docker interface? I would also need access to the user’s home folder. As mentioned earlier, Wilfred allows the user to specify a path to which Wilfred will store server data. Usually, this is within the home folder of the user but the ideal solution would be to request authorization to access a specific path on-the-fly to snapd (so the user can pick any path, regardless if it’s in the home folder or not). Any other data is stored within the snap confinement itself.

29

You would adjust your snap to use:

apps:
  foo:
    plugs:
    - home
    - removeable-media
    - docker

Yes, you would need a snap declaration for use of the docker interface, but we can convert this request to that.

As for other paths, there is the gtk3 file dialog (that can be made to use portals) and future snapd work to allow users to let a snap use other paths (eg, via prompting).

30

I have made the necessary changes in a pull request for my project (https://github.com/wilfred-dev/wilfred/pull/40/files, does it look ok?).

My application is solely command-line, would it be possible to do “path permission prompting” from the command-line instead of using a gtk3 file dialog? Should I open this as a feature request/issue somewhere, and if so, where (I’d be happy to do so)?

31

Prompting is not yet available for the command line but is actively being investigated. When there is something for people to try out, an announcement will be made in the forum.

32

Is there an issue for this on some issue tracker that I can follow?

33

Not yet - but we hope to be able to provide more details in the future.

34

Hi again, I saw snapd version 2.44 was just released. I am on Ubuntu 18.04, will snapd be updated on bionic so people can use my snap properly?

35

Hi again.

My system is running 2.44.1 and I still have this issue (e.g. unable to access Docker socket within confinement).

This is the snapcraft.yml config I use.

36

Sorry for double posting: when I do snap run --shell wilfred and which docker it is not found. Is that related?

Version info.

snap    2.44.1
snapd   2.44.1
series  16
ubuntu  18.04
kernel  5.3.0-45-generic
37

If you also want to use the docker command from the docker snap, you need to plug it’s content snap docker:docker-executables, i.e. add this to your snapcraft.yaml:

plugs:
  docker-executables:
    interface: content
    target: $SNAP/docker-snap
    default-provider: docker

then connect this plug to the docker snap:

snap connect wilfred:docker-executables docker:docker-executables

and now you can use docker executables from the docker snap:

$ snap connect myapp:docker-executables docker:docker-executables
$ snap connect myapp:docker docker:docker-daemon
$ snap connections myapp
Interface                    Plug                      Slot                       Notes
content[docker-executables]  myapp:docker-executables  docker:docker-executables  manual
docker                       myapp:docker              docker:docker-daemon       manual
$ snap run --shell myapp
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

$ $SNAP/docker-snap/bin/docker run hello-world | grep "Hello"
Hello from Docker!
38

The application itself doesn’t use the Docker executable, it uses the Docker socket directly. I just thought I’d mention it if it is related. I use docker-py with docker.from_env() so it should pick up the Unix socket (though it doesn’t work inside the snap even after 2.44).

39

Ah, in this case then it is expected that the docker executable is not found. The docker interface only provides access to the socket, nothing more.

40

Yes, I figured that much now. Any idea why it is still not working?

41

can you clarify how it is not working?

BTW, for reviewers or others who come here looking for an example of using the docker snap from another strict snap, I made an example snap here: https://github.com/anonymouse64/docker-snap-usage-example that can be used as reference