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