Auto-connect and alias request for uncomplicated-vm-tools


I’ve created the uncomplicated-vm-tools snap. uncomplicated-vm-tools is essentially a wrapper for virsh and virt-install for both making VM creation repeatable and to help batch commands to multiple VMs.

This topic is to request:

  • the uvt alias for consistency with the current usage
  • auto-connection for gpg-public-keys (required to add user GPG key to the VM)
  • auto-connection for libvirt (required to interact with libvirt daemon)
  • auto-connection for etc-default-keyboard (read access to /etc/default/keyboard via system-files required to configure the VM with user keyboard configuration by default)
  • auto-connection for run-libvirt-libvirt-sock-ro (read/write access to /run/libvirt/libvirt-sock-ro via system-files until a new version of snapd including this this PR would be released.)

Additionally I would like to ask for manual connection to the following interfaces, what would enable the snap to work with already existent configurations (in the so called ‘compatibility mode’):

  • ssh-keys required to get the ssh keys used to connect to the VM
  • dot-uvt-dot-conf (read access to $HOME/.uvt.conf via personal-files which is the configuration file used by uvt)
  • dot-cache-virt-manager-virt-install-dot-log (write access to $HOME/.cache/virt-manager/virt-install.log via personal-files where virt-install writes during VM creation)
  • dot-config-virt-viewer-settings (read access to $HOME/.config/virt-viewer/settings via personal-files which is required by virt-viewer to work)


(Whilst I know some of these answers myself, it is a good idea to get them down here so that it is transparent, so I am asking nonetheless)

  • Can you please point to any existing documentation which outlines the uvt name?
  • Can you explain a bit more about the ‘compatibility mode’? Why not auto-connect these as well?
  • Should /etc/default/keyboard perhaps be added to the base template in snapd since this feels like something that other snaps would require access to?
  • Should the virt-viewer settings and virt-install log use $HOME rather than $SNAP_REAL_HOME and so be local to the uvt snap? Why try and share these with the host?

Regarding voting then:

  • +1 from me for auto-connect of gpg-public-keys, libvirt and the system-files instance named run-libvirt-libvirt-sock-ro until the newer version of snapd is available
  • Whilst you haven’t requested it, I think the dot-uvt-dot-conf should be auto-connect since this snap is the clear owner of that path (but I think this might be better named dot-uvt-conf instead)
  • +1 from me for use of but not auto-connect for ssh-keys

Hi @alexmurray ,

Following wiki shows how the tool was tradicionaly configured and used. There you can see several calls to the uvt command

uvt has been slightly modified to better fit snap philosophy. By default, $HOME is set in $SNAP_USER_COMMON, and all the required configuration, ssh_keys, isos and VMs are stored there. That makes the snap totally auto contained, guaranteeing a clean environment upon removal of the snap.

Whilst this is the preferred usage for new installations, there are a lot of already existent deployments that can also benefit from this snap. That’s where the compat mode comes into play. If the $UVT_SNAP_COMPAT env variable is set, the snap will change its home directory to the real home ($SNAP_REAL_HOME). Only in this case access to ssh-keys, dot-uvt-dot-conf, dot-cache-virt-manager-virt-install-dot-log and dot-config-virt-viewer-settings interfaces are required.

Considering that ssh-keys, dot-uvt-dot-conf, dot-cache-virt-manager-virt-install-dot-log and dot-config-virt-viewer-settings are only required for the compatibility mode, that either all or none of them are required and that I expect uvt users being able to manually connect those interfaces if required (following the documentation that would be updated accordingly) I decided to only require manual connection to guarantee the minimum privilege principle.

I’ve opened a PR, so we can have there the discussion. I’ll be great if I can get auto-connection for this one also until the change would be released ^^

Those are only required in the compat mode. I think that makes sense (specially virt-viewer settings) to be consistent with the original behaviour

@pedronis, your view on adding /etc/default/keyboard to base template as per ?

Hey, I would like to additionally request read permissions to /var/lib/snapd/hostfs/var/lib/libvirt/dnsmasq via system-files until a new version of snapd including this PR would be released

Given your reasoning, +1 from me for auto-connecting:

  • gpg-public-keys
  • libvirt
  • etc-default-keyboard
  • run-libvirt-libvirt-sock-ro

and allow-connection on:

  • ssh-keys
  • dot-uvt-dot-conf
  • dot-cache-virt-manager-virt-install-dot-log
  • dot-config-virt-viewer-settings

additionally, +1 on the uvt as there doesn’t seem to be a conflict other than the same tool itself.

To clarify, is the hostfs-var-lib-libvirt-dnsmasq system-files interface request as an auto-connection or just connection?

Hi @cav

I’m requesting auto-connection for hostfs-var-lib-libvirt-dnsmasq system-files as it is required by libnss_libvirt to work. The PR adding this rule to libvirt interface has already been merged to snapd master, so this additional hostfs-var-lib-libvirt-dnsmasq system-files could be removed once the new snapd version would be released (as happens to /etc/default/keyboard and /run/libvirt/libvirt-sock-ro). I will keep track of it.



Whilst we wait on more votes from @reviewers on the request for the alias and the following interfaces:

  • dot-cache-virt-manager-virt-install-dot-log
  • dot-config-virt-viewer-settings

I will go ahead and make the declaration updates for:

  • gpg-public-keys
  • libvirt
  • etc-default-keyboard
  • run-libvirt-libvirt-sock-ro
  • ssh-keys
  • dot-uvt-dot-conf
  • hostfs-var-lib-libvirt-dnsmasq

given that there are +2 votes, 0 against. This is now live.

1 Like

+1 as well from me for use but not auto-connect of:

Since those are only needed in compatibility mode. Thanks @jslarraz for taking care of ensuring the min privileges needed. +2 votes for, 0 votes against. This is now live.

+1 from me as well for the requested auto alias since I don’t find any conflicting situation that would prevent this to be allowed. +2 votes for, 0 votes against. This is now live.

I see both PRs have been merged but are not released yet so please @jslarraz let us know when this is available and we can remove the extra accesses granted.

PR 13625 and PR 13602 is included in snapd 2.62 that is now available in snapd 2.62 in the beta channel.

Any test feedback would be appreciated.

For the record, snapd 2.62 is now available in stable channel. I’m removing etc-default-keyboard, run-libvirt-libvirt-sock-ro and hostfs-var-lib-libvirt-dnsmasq interfaces (and declarations allowing their use) as they are not needed anymore.