[libvirt PATCH 0/2] ci: Fixes to enable upstream QEMU integration tests on Fedora 36
- CVE-2022-24765 handling (>= git-2.35.2) - SELinux relabel the QEMU installation from source Successful pipeline: https://gitlab.com/eskultety/libvirt/-/pipelines/557712098 Erik Skultety (2): ci: integration: SELinux relabel the QEMU we installed from git ci: integration: Set 'safe.directory' when installing QEMU from git ci/integration-template.yml | 6 ++++++ 1 file changed, 6 insertions(+) -- 2.36.1
Signed-off-by: Erik Skultety <eskultet@redhat.com> --- ci/integration-template.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/ci/integration-template.yml b/ci/integration-template.yml index e2ccebd1f6..a04c72acbf 100644 --- a/ci/integration-template.yml +++ b/ci/integration-template.yml @@ -98,3 +98,4 @@ - !reference [.integration_tests, before_script] - cd "$SCRATCH_DIR" - *qemu-build-template + - sudo restorecon -R /usr -- 2.36.1
On Wed, Jun 08, 2022 at 07:59:36AM +0200, Erik Skultety wrote:
Signed-off-by: Erik Skultety <eskultet@redhat.com> --- ci/integration-template.yml | 1 + 1 file changed, 1 insertion(+)
Reviewed-by: Andrea Bolognani <abologna@redhat.com> -- Andrea Bolognani / Red Hat / Virtualization
Since a fix for CVE-2022-24765 was released every git command is now checked against the context repo in which it's supposed to run resulting in a fatal error if the repo is owned by other user than the one running the git command. This means that in order to be able to do 'sudo make install', we have to set the 'safe.directory' for the root user. This is because QEMU runs 'git submodule update' automatically on 'make install'. Signed-off-by: Erik Skultety <eskultet@redhat.com> --- ci/integration-template.yml | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/ci/integration-template.yml b/ci/integration-template.yml index a04c72acbf..a1fecbb78d 100644 --- a/ci/integration-template.yml +++ b/ci/integration-template.yml @@ -16,6 +16,11 @@ then make -j"$JOBS" check-build; fi + + # we need the following since the fix for CVE-2022-24765 now causes a fatal + # error if a user issues a git command from within a directory owned by some + # other user + - sudo git config --global --add safe.directory "$SCRATCH_DIR/qemu" - sudo make install -- 2.36.1
On Wed, Jun 08, 2022 at 07:59:37AM +0200, Erik Skultety wrote:
Since a fix for CVE-2022-24765 was released every git command is now checked against the context repo in which it's supposed to run resulting in a fatal error if the repo is owned by other user than the one running the git command. This means that in order to be able to do 'sudo make install', we have to set the 'safe.directory' for the root user. This is because QEMU runs 'git submodule update' automatically on 'make install'.
Signed-off-by: Erik Skultety <eskultet@redhat.com> ---
FWIW we could alternatively update the submodules manually, but we'd have list them explicitly, IOW: $ git clone qemu ... $ cd qemu.git $ scripts/git-submodule.sh ui/keycodemapdb dtc slirp $ mkdir build && cd build $ ../configure ... --with-git-submodules=ignore $ make -jN && sudo make install Erik
On Wed, Jun 08, 2022 at 08:03:07AM +0200, Erik Skultety wrote:
FWIW we could alternatively update the submodules manually, but we'd have list them explicitly, IOW: $ git clone qemu ... $ cd qemu.git $ scripts/git-submodule.sh ui/keycodemapdb dtc slirp
We could avoid hardcoding the names of the submodules by using something along the lines of $ ./scripts/git-submodule.sh update $(git submodule | awk '{print $2}' | grep -Ev '^(meson|roms/.*|tests/.*)$') A bit of a mouthful, but should be solid enough.
$ mkdir build && cd build $ ../configure ... --with-git-submodules=ignore
Using --with-git-submodules=validate would work too, since we'd have updated the submodules beforehand. I think I would prefer this approach to changing the git configuration for the root user. -- Andrea Bolognani / Red Hat / Virtualization
On Thu, Jun 09, 2022 at 06:01:34AM -0400, Andrea Bolognani wrote:
On Wed, Jun 08, 2022 at 08:03:07AM +0200, Erik Skultety wrote:
FWIW we could alternatively update the submodules manually, but we'd have list them explicitly, IOW: $ git clone qemu ... $ cd qemu.git $ scripts/git-submodule.sh ui/keycodemapdb dtc slirp
We could avoid hardcoding the names of the submodules by using something along the lines of
$ ./scripts/git-submodule.sh update $(git submodule | awk '{print $2}' | grep -Ev '^(meson|roms/.*|tests/.*)$')
A bit of a mouthful, but should be solid enough.
$ mkdir build && cd build $ ../configure ... --with-git-submodules=ignore
Using
--with-git-submodules=validate
would work too, since we'd have updated the submodules beforehand.
'validate' will still cause QEMU to run git commands to check the submodule state, so I presume it'll still hit the problem of ownership.
I think I would prefer this approach to changing the git configuration for the root user.
I was going to say the opposite. Updating the root user git config is harmless since our integration suite is intended to always run inside a single use throwaway VM. IOW, we already assume the VM is compromised at the end of every test cycle. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Thu, Jun 09, 2022 at 11:07:57AM +0100, Daniel P. Berrangé wrote:
On Thu, Jun 09, 2022 at 06:01:34AM -0400, Andrea Bolognani wrote:
On Wed, Jun 08, 2022 at 08:03:07AM +0200, Erik Skultety wrote:
FWIW we could alternatively update the submodules manually, but we'd have list them explicitly, IOW: $ git clone qemu ... $ cd qemu.git $ scripts/git-submodule.sh ui/keycodemapdb dtc slirp
We could avoid hardcoding the names of the submodules by using something along the lines of
$ ./scripts/git-submodule.sh update $(git submodule | awk '{print $2}' | grep -Ev '^(meson|roms/.*|tests/.*)$')
A bit of a mouthful, but should be solid enough.
$ mkdir build && cd build $ ../configure ... --with-git-submodules=ignore
Using
--with-git-submodules=validate
would work too, since we'd have updated the submodules beforehand.
'validate' will still cause QEMU to run git commands to check the submodule state, so I presume it'll still hit the problem of ownership.
Yes, only the 'ignore' option value is viable here.
I think I would prefer this approach to changing the git configuration for the root user.
I was going to say the opposite. Updating the root user git config is harmless since our integration suite is intended to always run inside a single use throwaway VM. IOW, we already assume the VM is compromised at the end of every test cycle.
Yes, thanks for bringing it up, ^this is the main reason why I didn't propose the submodule approach in the first place. Erik
On Thu, Jun 09, 2022 at 12:46:38PM +0200, Erik Skultety wrote:
On Thu, Jun 09, 2022 at 11:07:57AM +0100, Daniel P. Berrangé wrote:
On Thu, Jun 09, 2022 at 06:01:34AM -0400, Andrea Bolognani wrote:
On Wed, Jun 08, 2022 at 08:03:07AM +0200, Erik Skultety wrote:
FWIW we could alternatively update the submodules manually, but we'd have list them explicitly, IOW: $ git clone qemu ... $ cd qemu.git $ scripts/git-submodule.sh ui/keycodemapdb dtc slirp
We could avoid hardcoding the names of the submodules by using something along the lines of
$ ./scripts/git-submodule.sh update $(git submodule | awk '{print $2}' | grep -Ev '^(meson|roms/.*|tests/.*)$')
A bit of a mouthful, but should be solid enough.
$ mkdir build && cd build $ ../configure ... --with-git-submodules=ignore
Using
--with-git-submodules=validate
would work too, since we'd have updated the submodules beforehand.
'validate' will still cause QEMU to run git commands to check the submodule state, so I presume it'll still hit the problem of ownership.
Yes, only the 'ignore' option value is viable here.
I think I would prefer this approach to changing the git configuration for the root user.
I was going to say the opposite. Updating the root user git config is harmless since our integration suite is intended to always run inside a single use throwaway VM. IOW, we already assume the VM is compromised at the end of every test cycle.
Yes, thanks for bringing it up, ^this is the main reason why I didn't propose the submodule approach in the first place.
Alrighty, Reviewed-by: Andrea Bolognani <abologna@redhat.com> to the original patch then :) -- Andrea Bolognani / Red Hat / Virtualization
On Thu, Jun 09, 2022 at 07:34:07AM -0400, Andrea Bolognani wrote:
On Thu, Jun 09, 2022 at 12:46:38PM +0200, Erik Skultety wrote:
On Thu, Jun 09, 2022 at 11:07:57AM +0100, Daniel P. Berrangé wrote:
On Thu, Jun 09, 2022 at 06:01:34AM -0400, Andrea Bolognani wrote:
On Wed, Jun 08, 2022 at 08:03:07AM +0200, Erik Skultety wrote:
FWIW we could alternatively update the submodules manually, but we'd have list them explicitly, IOW: $ git clone qemu ... $ cd qemu.git $ scripts/git-submodule.sh ui/keycodemapdb dtc slirp
We could avoid hardcoding the names of the submodules by using something along the lines of
$ ./scripts/git-submodule.sh update $(git submodule | awk '{print $2}' | grep -Ev '^(meson|roms/.*|tests/.*)$')
A bit of a mouthful, but should be solid enough.
$ mkdir build && cd build $ ../configure ... --with-git-submodules=ignore
Using
--with-git-submodules=validate
would work too, since we'd have updated the submodules beforehand.
'validate' will still cause QEMU to run git commands to check the submodule state, so I presume it'll still hit the problem of ownership.
Yes, only the 'ignore' option value is viable here.
I think I would prefer this approach to changing the git configuration for the root user.
I was going to say the opposite. Updating the root user git config is harmless since our integration suite is intended to always run inside a single use throwaway VM. IOW, we already assume the VM is compromised at the end of every test cycle.
Yes, thanks for bringing it up, ^this is the main reason why I didn't propose the submodule approach in the first place.
Alrighty,
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
to the original patch then :)
Pushed. Thanks, Erik
participants (3)
-
Andrea Bolognani -
Daniel P. Berrangé -
Erik Skultety