Expose an executable on the host to a snap

snapcraft
1

I am implementing a feature for my snap that requires using the docker ps and docker inspect commands to find Docker containers created from certain Docker images.

I need to expose the docker executable to my snap. Ideally, I’d like to create a symlink somewhere in the snap’s directory pointing to the executable on the host.

I cannot use the Docker snap, because I cannot assume a user is using it instead of the standard Docker installation. I do not expect containers launched/maintained by the host engine would be the same as those launched/maintained by the snap engine.

I have tried using both layout and parts.<part-name>.override-build to no success.

For reference, here is my current snapcraft.yaml:

name: storage-explorer
version: "1.35.0"
summary: Optimize your Azure storage management
description: |
  Upload, download, and manage Azure blobs, files, queues, and tables, as well
  as Azure Data Lake Storage entities. Easily access virtual
  machine disks, and work with either Azure Resource Manager or classic storage
  accounts. Manage and configure cross-origin resource sharing rules.

base: core20
grade: stable
confinement: strict

architectures:
  - build-on: amd64

parts:
  # Add the dotnet runtime apt repository to the build environment.
  dotnet-repo:
    plugin: nil
    build-packages:
      - apt-transport-https
      - wget
    override-build: |
      wget -q https://packages.microsoft.com/config/ubuntu/20.04/packages-microsoft-prod.deb
      dpkg -i packages-microsoft-prod.deb
      apt-get -y update

  # Stage the dotnet runtime, and its requirements, inside the snap.
  #  - https://docs.microsoft.com/dotnet/core/install/linux-ubuntu
  dotnet:
    after:
      - dotnet-repo
    plugin: nil
    stage-packages:
      - dotnet-runtime-8.0
      - libcurl4
      - libicu66
      - libkrb5-3
      - liblttng-ust0
      - libssl1.1
      - zlib1g

  storage-explorer:
    after:
      - dotnet
    plugin: dump
    source: ./src/Standalone/bin/StorageExplorer-linux-x64.tar.gz
    stage-packages:
      - iproute2
      - libasound2
      - libatm1
      - libgconf-2-4
      - gnome-keyring
      - libnspr4
      - libnss3
      - libpulse0
      - libsecret-1-0
      - libx11-xcb1
      - libxss1
      - libxtables12
      - libxtst6
      - xdg-utils
      - libxcb-dri3-0
      - libdrm2
      - libgbm1
    prime:
      - -usr/bin/xdg-open

apps:
  storage-explorer:
    command: StorageExplorerSnap
    extensions: [gnome-3-38]
    environment:
      # Correct the TMPDIR path for Chromium Framework/Electron to
      # ensure libappindicator has readable resources
      TMPDIR: $XDG_RUNTIME_DIR
      # Fallback to XWayland if running in a Wayland session.
      DISABLE_WAYLAND: 1
      # Make sure .NET Core knows the install location in the Snap.
      DOTNET_ROOT: $SNAP/usr/share/dotnet
    plugs:
      - browser-support
      - home
      - mount-observe
      - network
      - password-manager-service
      - pulseaudio
      - removable-media
      - unity7
2

@Wimpress @jdstrand @ijohnson Apologies for the direct ping. I have no idea if this has reached any eyes, and I’d like to try and tackle this problem. Any input would be helpful.

3

Hey @craxal, I’m not current on the latest developments with snaps, but the design of the sandbox is such that anything executed by the snap will fall under the confinement of your snap, so the symlink approach wouldn’t work.

When I was developing on snapd, you could’ve potentially shipped a binary that knows how to speak to dockerd over the docker socket (and plugs docker-support), but this interface has a lot of privileges and snaps using it undergo more scrutiny and its not guaranteed that your snap would be distributable in the snap store while plugging this interface.

Before you go this route, I suggest reaching out to the @review-team to see if your snap could be eligible for this or if there are other options available to you these days.

Good luck!

4

@jdstrand Thank you for the response. What would this binary that knows how to speak to dockerd over the docker socket look like? I’m worried about this going deeper into the weeds than we can afford. I’d like to get a sense of what amount of engineering this will take before trying to get @review-team involved.