7:37 p.m.
On Jun 27, Nicolas Quiniou-Briand wrote:
>To check if you can access libvirt from your user account, you can
run:
>
> virsh -c qemu:///system sysinfo
It failed:
```
gitlab-runner@ci:~$ id
uid=998(gitlab-runner) gid=995(gitlab-runner)
groups=995(gitlab-runner),112(kvm),1001(libvirtd)
gitlab-runner@ci:~$ virsh -c qemu:///system sysinfo
** (process:13177): CRITICAL **: polkit_unix_process_set_property: assertion
'val != -1' failed
==== AUTHENTICATING FOR org.libvirt.unix.manage ===
System policy prevents management of local virtualized systems
Authenticating as: Debian (debian)
Password:
```
Did you configure libvirt service with debops.libvirtd? By default the
'auth_unix_rw' in the /etc/libvirt/libvirtd.conf config file is disabled which
should result in 'none', which should disable PolicyKit. Unless the default
changed in Stretch, I haven't checked, or polkit is enabled with PolicyKit is
present on the host.
Running with sudo will ask a password.
That's correct, since gitlab-runner user does not get any special sudo
configuration apart from running chmod on image files to allow creation of
vagrant boxes.
I try to use a Polkit rule [0] with the `libvirtd` group without
success.
This rule is written in JavaScript, which is supported in polkit1. Debian
Stretch still uses polkit 0.105 which uses the older syntax. I was hesitant
about supporting PolicyKit in DebOps before because I hoped that Debian would
switch to the newer version that uses JavaScript rules, but since it will not
happen for at least 2 years (Buster comes with 0.105 version as well), I think
that we can just commit to the old version.
According to [1], if I create following file under
/etc/polkit-1/localauthority/50-local.d/gitlab-runner.pkla:
```
[Allow gitlab-runner libvirt management permissions]
Identity=unix-user:gitlab-runner
Action=org.libvirt.unix.manage
ResultAny=yes
ResultInactive=yes
ResultActive=yes
```
then restart `polkit` and `libvirtd`, I'm able to run `virsh -c
qemu:///system sysinfo` as gitlab-runner user without password.
Hmm, do you have to restart libvirtd service as well? Can you check if only
a restart (or better yet reload) of polkit service works?
Maciej, I supposed you don't use Polkit on your CI
infrastructure.
No my GitLab Runner host I only see these packages:
#v+
drybjed:root@node07 /var/local/drybjed/ # dpkg -l | grep polkit
ii libpolkit-agent-1-0:amd64 0.105-18+deb9u1 amd64
PolicyKit Authentication Agent API
ii libpolkit-backend-1-0:amd64 0.105-18+deb9u1 amd64
PolicyKit backend API
ii libpolkit-gobject-1-0:amd64 0.105-18+deb9u1 amd64
PolicyKit Authorization API
drybjed:root@node07 /var/local/drybjed/ # dpkg -l | grep policykit
ii policykit-1 0.105-18+deb9u1 amd64
framework for managing administrative policies and privileges
#v-
It would be interesting to reproduce your issue first. Can you tell me more
about your environment? Is that Debian Stretch? Can you check the parameters
'auth_unix_rw' and 'auth_unix_ro' in /etc/libvirt/libvirtd.conf to see if
they
are active and their value?
1. Which configuration do you use ?
I'm using the defaults set up by DebOps, with roles ifupdown, libvirtd,
libvirtd_qemu, gitlab_runner. Not much changes via the inventory. It would be
interesting to find what are the differences between your environment and
mine.
2. According to [1], I supposed libvirtd comes with PolKit support in
Debian
Stretch. IMO, we should adapt debops.libvirtd defaults to have a ready to
use setup with a gitlab-runner.
Sure, it might be useful to expand the 'debops.libvirtd' a bit to handle more
authentication schemes. Adding PolicyKit support first sounds like a good
idea, although I think that the specific configuration file should be added by
the 'debops.gitlab_runner' role so that it is active when GitLab Runner is set
up on that host.
Cheers,
Maciej