Hello, the canonical-livepatch snap has added a new system-files plug - hostfs-dpkg-data. Please review and allow the use of this plug.
The purpose of this plug is to allow read-only access to the following files:
/var/lib/snapd/hostfs/var/lib/dpkg and /etc/dpkg.
These files link in the following layout:
/usr/share/dpkg:
bind: $SNAP/usr/share/dpkg
/usr/bin/dpkg:
symlink: $SNAP/dpkg
/etc/dpkg/dpkg.cfg:
bind-file: $SNAP/etc/dpkg/dpkg.cfg
/var/lib/dpkg/status:
symlink: $SNAP/dpkg-status-file
This is so that the livepatch-client can read the list of kernel images installed on the host machine.
- name: canonical-livepatch
- description: Canonical Livepatch patches high and critical linux kernel vulnerabilities removing the immediate need to reboot to upgrade the kernel, instead allowing the downtime to be scheduled. It is a part of the Ubuntu Pro offering. The Canonical Livepatch Client is an application that runs on your machine and periodically checks for patches. See our docs at https://ubuntu.com/security/livepatch/docs/livepatch
- snapcraft: PRIVATE
- upstream: PRIVATE
- upstream-relation: Canonical owned and developed snap, I am an engineer working on this project
- interfaces:
- system-files:
- request-type: installation
- reasoning: read the list of kernel images installed on the host machine (please see above)
This request has been added to the queue for review by the @reviewers team.
This request looks legit to me. +1 from me for read access to /var/lib/snapd/hostfs/var/lib/dpkg and /etc/dpkg
Hey @gaborbk
The access request sounds reasonable to me.
These files link in the following layout:
From this commentary I understand that your idea is to make dpkg/status file from the host accessible inside the snap (at /var/lib/dpkg/status). If that’s the case, I don’t don’t it would work with the proposed layouts unless I’m missing somehting. (#askForInfo)
Hey @jslarraz thank you for your review!
Maybe I’m missing something - I’m quite new to snaps I admit - so I added a version of snapcraft.yaml below with all irrelevant information removed. If the current setup with the new dpkg layout or plug wouldn’t work, could you please share why and how you would suggest changing it?
plugs:
...other plugs...
hostfs-dpkg-data:
# We need this plug to get the list of kernel images installed on the host
# machine.
#
# These are good references/examples on how to have `dpkg` available in snap
# runtime:
# - Discussion: https://forum.snapcraft.io/t/classic-confinement-for-ubuntu-package-manifest-snap/20543/5
# - An example: https://github.com/canonical/ubuntu-package-manifest/blob/982c61d5d2fa25f150fe31a713f3b3bb08c709a3/snap/snapcraft.yaml
#
interface: system-files
read:
- /var/lib/snapd/hostfs/var/lib/dpkg
- /etc/dpkg
layout:
/usr/share/dpkg:
bind: $SNAP/usr/share/dpkg
/usr/bin/dpkg:
bind-file: $SNAP/usr/bin/dpkg
/etc/dpkg/dpkg.cfg:
bind-file: $SNAP/etc/dpkg/dpkg.cfg
apps:
canonical-livepatchd:
command: canonical-livepatchd
plugs:
...other plugs...
- hostfs-dpkg-data
environment:
# This will point dpkg to see the host's data. If this env var is not set
# then dpkg will see the packages installed in the confined snap environment.
DPKG_ADMINDIR: /var/lib/snapd/hostfs/var/lib/dpkg
canonical-livepatch:
command: canonical-livepatch
plugs:
...other plugs...
parts:
canonical-livepatch:
...irrelevant config...
dpkg-binary:
plugin: nil
stage-packages:
- dpkg
motd:
...irrelevant config...
keys:
...irrelevant config...
hooks:
plugin: dump
source: ./snaps/client/core22/hooks
organize:
...irrelevant config...
It looks good to me. Thanks for clarifying 
Could you please adjust your interface definition to follow the usual conventions? To do so please split your system-files interface in two different interfaces (one per path) and name them following the naming convention (hostfs-var-lib-dpkg and etc-dpkg)
Thanks a lot
Thank you
I have updated the definition, once you approve the new interfaces I can push the new snap revision containing the changes.
