- 14 May, 2021 6 commits
-
-
Tim Wiederhake authored
Signed-off-by:
Tim Wiederhake <twiederh@redhat.com> Reviewed-by:
Laine Stump <laine@redhat.com>
-
Tim Wiederhake authored
Signed-off-by:
-
Tim Wiederhake authored
Signed-off-by:
-
Tim Wiederhake authored
Signed-off-by:
-
Tim Wiederhake authored
Signed-off-by:
-
Tim Wiederhake authored
Signed-off-by:
-
- 13 May, 2021 15 commits
-
-
Daniel P. Berrangé authoredA secret can be marked with the "private" attribute. The intent was that it is not possible for any libvirt client to be able to read the secret value, it would only be accesible from within libvirtd. eg the QEMU driver can read the value to launch a guest. With the modular daemons, the QEMU, storage and secret drivers are all running in separate daemons. The QEMU and storage drivers thus appear to be normal libvirt client's from the POV of the secret driver, and thus they are not able to read a private secret. This is unhelpful. With the previous patches that introduced a "system token" to the identity object, we can now distinguish APIs invoked by libvirt daemons from those invoked by client applications. Reviewed-by:
Michal Privoznik <mprivozn@redhat.com> Signed-off-by:
Daniel P. Berrangé <berrange@redhat.com> -
Daniel P. Berrangé authored
When fetching the value of a private secret, we need to use an elevated identity otherwise the secret driver will deny access. When using the modular daemons, the elevated identity needs to be active before the secret driver connection is opened, and it will apply to all APIs calls made on that conncetion. When using the monolithic daemon, the identity at time of opening the connection is ignored, and the elevated identity needs to be active precisely at the time the virSecretGetValue API call is made. After acquiring the secret value, the elevated identity should be cleared. This sounds complex, but is fairly straightfoward with the automatic cleanup callbacks. Reviewed-by:
Daniel P. Berrangé <berrange@redhat.com> -
Daniel P. Berrangé authored
The drivers can all call virGetConnectXXX to open a connection to a secondary driver. For example, when creating a encrypted storage volume, the storage driver has to open a secret driver connection, or when starting a guest, the QEMU driver has to open the network driver to lookup a virtual network. When using monolithic libvirtd, the connection has the same effective identity as the client, since everything is still in the same process. When using the modular daemons, however, the remote daemon sees the identity of the calling daemon. This is a mistake as it results in the modular daemons seeing the client with elevated privileges. We need to pass on the current identity explicitly when opening the secondary drivers. This is the same thing that is done by daemon RPC dispatcher code when it is directly forwarding top level API calls from virtproxyd and other daemons. Reviewed-by: -
Daniel P. Berrangé authored
This is essentially a way to determine if the current identity is that of another libvirt daemon. Reviewed-by:
Daniel P. Berrangé <berrange@redhat.com> -
Daniel P. Berrangé authored
When talking to the secret driver, the callers inside libvirt daemons need to be able to run with an elevated privileges that prove the API calls are made by a libvirt daemon, not an end user application. The virIdentityElevateCurrent method will take the current identity and, if not already present, add the system token. The old current identity is returned to the caller. With the VIR_IDENTITY_AUTORESTORE annotation, the old current identity will be restored upon leaving the codeblock scope. ... early work with regular privileges ... if (something needing elevated privs) { VIR_IDENTITY_AUTORESTORE virIdentity *oldident = virIdentityElevateCurrent(); if (!oldident) return -1; ... do something with elevated privileges ... } ... later work with regular privileges ... Reviewed-by:Daniel P. Berrangé <berrange@redhat.com> -
Daniel P. Berrangé authored
Reviewed-by:
Daniel P. Berrangé <berrange@redhat.com> -
Daniel P. Berrangé authored
Reviewed-by:
Daniel P. Berrangé <berrange@redhat.com> -
Daniel P. Berrangé authored
When creating the system identity set the system token. The system token is currently stored in a local path /var/run/libvirt/common/system.token Obviously with only traditional UNIX DAC in effect, this is largely security through obscurity, if the client is running at the same privilege level as the daemon. It does, however, reliably distinguish an unprivileged client from the system daemons. With a MAC system like SELinux though, or possible use of containers, access can be further restricted. A possible future improvement for Linux would be to populate the kernel keyring with a secret for libvirt daemons to share. Reviewed-by:
Daniel P. Berrangé <berrange@redhat.com> -
Daniel P. Berrangé authored
We want a way to distinguish between calls from a libvirt daemon, and a regular client application when both are running as the same user account. This is not possible with the current set of attributes recorded against an identity, as there is nothing that is common to all of the modular libvirt daemons, while distinct to all other processes. We thus introduce the idea of a system token, which is simply a random hex string that is only known by the libvirt daemons, to be recorded against the system identity. Reviewed-by:
Daniel P. Berrangé <berrange@redhat.com> -
Daniel P. Berrangé authored
A random token is simply a string of random bytes formatted in hexidecimal. Reviewed-by:
Daniel P. Berrangé <berrange@redhat.com> -
Neal Gompa (ニール・ゴンパ) authored
The libvirt-daemon package now provides the 'libvirt-admin' virtual name, but the Provides stanza doesn't declare version information, which breaks things depending on that package using a versioned dependency. Fix this by setting the version-release of libvirt to that name to mimic the previous state. Fixes: 2244ac16 Signed-off-by:
Neal Gompa <ngompa13@gmail.com> Reviewed-by:
-
Tim Wiederhake authored
Signed-off-by:
-
Tim Wiederhake authored
Signed-off-by:
-
Tim Wiederhake authored
Signed-off-by:
-
Tim Wiederhake authored
Signed-off-by:
-
- 12 May, 2021 8 commits
-
-
Daniel P. Berrangé authored
In the distros using RPMs, we build libvirt once as a side effect of running "ninja dist", and once via rpmbuild. In addition "ninja dist" will run all tests including the "syntax-check" suite, despite use having a separate "codestyle" job for for that. There is no way to pass "--no-suite" when creating the dist, but if we switch to invoking "meson dist", we can skip the build+test part entirely using "--no-tests". When doing this we then run explicit "meson compile" and "meson test" commands for the distros that don't build the RPMs, and in the latter case we can now skip the "syntax-check" suite. The RPM builds already skipped the "syntax-check" suite. Reviewed-by:
Daniel P. Berrangé <berrange@redhat.com> -
Daniel P. Berrangé authored
The "dist" and "test" targets in ninja end up calling back into the equivalent meson commands. The meson commands support various arguments that are not accessible when invoked via ninja, so it is preferrable to use meson directly. Reviewed-by:
Daniel P. Berrangé <berrange@redhat.com> -
Daniel P. Berrangé authored
The "DIST=skip" flag as used in CentOS 7 jobs to workaround a problem with older git versions. This is no longer required since commit d35003ae Author: Andrea Bolognani <abologna@redhat.com> Date: Tue May 4 10:45:29 2021 +0200 ci: Drop CentOS 7 Reviewed-by:
Daniel P. Berrangé <berrange@redhat.com> -
Daniel P. Berrangé authored
"meson test" will only print a list of which tests fail by default, so we were sending the full test log to stdout on failure. This makes it really hard to see the errors though as the test log has all succcesful tests too. "ninja test" will print the same as "meson test", following by details of each failure. It does this using the "--print-errorlog" flag, so lets use that in the codestyle job. Reviewed-by:
Daniel P. Berrangé <berrange@redhat.com> -
Neal Gompa (ニール・ゴンパ) authored
This is automatically picked up by the dependency generator, so there's no reason to have this here. Signed-off-by:
Andrea Bolognani <abologna@redhat.com>
-
Andrea Bolognani authored
No need to check whether we're on Fedora, because checking whether the version of Fedora is recent enough implictly does that already. Signed-off-by:
-
Andrea Bolognani authored
It's only used in one place, and it's nicer to keep the error message close to the check that causes it to be emitted. Signed-off-by:
-
Andrea Bolognani authored
The rewritten checks, which made it possible to drop the variable, are in fact not equivalent to the original ones, and rewriting them once again so that they are would make them unwieldy. Let's go back to how things were. Reverts: 69c8d595 Signed-off-by:
-
- 11 May, 2021 11 commits
-
-
Tim Wiederhake authored
Signed-off-by:
-
Tim Wiederhake authored
Signed-off-by:
-
Tim Wiederhake authored
Signed-off-by:
-
Tim Wiederhake authored
Signed-off-by:
-
Tim Wiederhake authored
Signed-off-by:
-
Tim Wiederhake authored
Signed-off-by:
-
Tim Wiederhake authored
Signed-off-by:
-
Tim Wiederhake authored
The width of `unsigned long` differs on 32 bit and 64 bit architectures. There is no compelling reason why the maximum DHCP lease time should depend on the architecture. Signed-off-by:
-
Tim Wiederhake authored
Signed-off-by:
-
Tim Wiederhake authored
Signed-off-by:
-
Kashyap Chamarthy authored
This is a rewrite of: https://wiki.libvirt.org/page/Live-merge-an-entire-disk-image-chain-including-current-active-disk Once this commit merges, the above wiki should point to this kbase document. Signed-off-by:Kashyap Chamarthy <kchamart@redhat.com> Signed-off-by:
-
