socket is inaccessible for libvirt-dbus

[Martin Pitt]

[Impact]

 * Due to the difference in auth mechanisms between Debian (polkit)
   and Ubuntu (group based) libvirt-dbus does not work as-is in
   Ubuntu.

 * Users would need to manually add a user to a group, but we
   should make the default install experience work.

[Test Case]

# should install fine
$ sudo apt-get install libvirt-dbus
# should be avail due to dependencies and look normal (as shown here)
$ ls -l /var/run/libvirt/libvirt-sock
srw-rw---- 1 root libvirt 0 Oct 5 05:50 /var/run/libvirt/libvirt-sock
# should be part of the "libvirt" group
$ id libvirtdbus
uid=997(libvirtdbus) gid=997(libvirtdbus) groups=997(libvirtdbus),122(libvirt)
# call should work
$ busctl call org.libvirt /org/libvirt/QEMU org.libvirt.Connect ListDomains u 0

bad:
Call failed: Failed to connect socket to '/var/run/libvirt/libvirt-sock': Permission denied
good:
ao 0

[Regression Potential]

 * The change only does the group add, no regression expected except a
   potential security issue. That was brought up and signed off by
   security in comment #13 =>
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1802005/comments/13

[Other Info]

 * The package also was an FTBFS which this upload fixes as well.
   That change is only to the build-time self tests, so again no change to
   the runtime behavior due to the changes.
   This FTFBS is only present with newer libvirt, and therefore the Focal
   SRU will only have the permissions change, but depending on timing the
   groovy upload might become a zero day SRU hence I wanted to mention.

----

Package: libvirt-dbus
Version: 1.2.0-1
DistroRelease: Ubuntu 18.10

libvirt-dbus seems to be completely broken for the system connection:

root:~# busctl call org.libvirt /org/libvirt/QEMU org.libvirt.Connect ListDomains u 0
Failed to connect socket to '/var/run/libvirt/libvirt-sock': Permission denied

root:~# ls -l /var/run/libvirt/libvirt-sock
srwxrwx--- 1 root libvirt 0 Nov 6 15:15 /var/run/libvirt/libvirt-sock

root:~# ps aux|grep libvirtd
root 1434 0.0 3.4 1038028 35212 ? Ssl 15:15 0:00 /usr/sbin/libvirtd

The same happens for a user that is in the "libvirt" group.

On Fedora and also Debian testing (which has the exact same libvirt-dbus package), the socket has permissions 777 instead of 770, where it works. I don't have an idea where the wrong permissions are set.

[Martin Pitt (pitti)]

Other users run into this as well: https://github.com/cockpit-project/cockpit/issues/13339

[Martin Pitt (pitti)]

Here as well: https://www.reddit.com/r/linuxquestions/comments/c7hcfe/whack_issues_with_cockpit_and_ubuntu_server_1904/

[dreamcat4 (dreamcat4)]

I too am also affected,

https://github.com/cockpit-project/cockpit/issues/13343

Please fix this if you can
Many thanks,

[Martin Pitt (pitti)]

The socket is actually owned by libvirt

[Christian Ehrhardt  (paelzer)]

Hi Martin o/

I have
srw-rw-rw- 1 root root 0 Feb 24 07:42 /var/run/libvirt/libvirt-sock=

And the command you posted just works:
# busctl call org.libvirt /org/libvirt/QEMU org.libvirt.Connect ListDomains u 0
ao 0

^^ that was in Focal.

Let me check releases back one by one ...

[Christian Ehrhardt  (paelzer)]

Eoan:

srwxrwx--- 1 root libvirt 0 Feb 24 15:32 /var/run/libvirt/libvirt-sock=

root@e:~# busctl call org.libvirt /org/libvirt/QEMU org.libvirt.Connect ListDomains u 0
Failed to connect socket to '/var/run/libvirt/libvirt-sock': Permission denied

[Martin Pitt (pitti)]

Nice, thanks Christian!

[Christian Ehrhardt  (paelzer)]

The permissions of the sockets are usually controlled by libvirtd.conf

$ grep '^unix_sock_' /etc/libvirt/libvirtd.conf
unix_sock_group = "libvirt"
unix_sock_ro_perms = "0777"
unix_sock_rw_perms = "0770"

The new version still has the config entry but ... "fortunately" ignores the config and sets 666 instead.

This is due to:
# This setting is not required or honoured if using systemd socket
# activation.

This is now controlled by:
# systemctl cat libvirtd.socket
# /lib/systemd/system/libvirtd.socket
[Unit]
Description=Libvirt local socket
Before=libvirtd.service

[Socket]
# The directory must match the /etc/libvirt/libvirtd.conf unix_sock_dir setting
# when using systemd version < 227
ListenStream=/run/libvirt/libvirt-sock
Service=libvirtd.service
SocketMode=0666

[Install]
WantedBy=sockets.target

It is time to drop the superfluous (now non functional) delta that changes the libvirtd.conf entries on the next merge. Going back this is a simple config change to expose the sockets a bit wider to the system than they are by default.

1. set in /etc/libvirt/libvirtd.conf
unix_sock_rw_perms = "0777"
(or any other perm that is sufficient for you)
2. restart libvirt
systemctl restart libvirtd

=> now the permission is opened up and libvirt-dbus works.
# ll /var/run/libvirt/libvirt-soc*
srwxrwx--- 1 root libvirt 0 Feb 24 15:32 /var/run/libvirt/libvirt-sock=
srwxrwxrwx 1 root libvirt 0 Feb 24 15:32 /var/run/libvirt/libvirt-sock-ro=
# busctl call org.libvirt /org/libvirt/QEMU org.libvirt.Connect ListDomains u 0
ao 0

Not sure if we want/need to make a change to the default config in <=Eoan.
@Martin please advise if you are of different opinion.

P.S. I've taken notes to drop the default config delta on the next merge.

[Martin Pitt (pitti)]

@Christian: Wontfix WFM, I'm glad that the default works in focal (the next LTS). For the non-LTS ones it can be worked around (write a systemd unit drop-in or so), but apparently it's not such a big issue. Thanks!

[Chris Routh (routhinator)]

This bug affects me in Focal (20.04) and is not resolved.

[Chris Routh (routhinator)]

I was able to manually workaround this on Ubuntu 20.04 with the file from here:

https://wiki.libvirt.org/page/Networking#Using_NetworkManager_directly

And the solution from here:

https://github.com/cockpit-project/cockpit/issues/13343#issuecomment-570611574

```
# ======
# install cockpit on ubuntu 19.10
sudo apt-get install -y cockpit cockpit-machines libvirt-dbus

# fix for issue 'machines list is empty'
# https://github.com/cockpit-project/cockpit/issues/13343
sudo usermod -a -G libvirt libvirtdbus
sudo usermod -a -G libvirt libvirt-qemu

# must reboot (or restart the affected systemd services) for changes to take effect
```

[Christian Ehrhardt  (paelzer)]

Hi Chris,
thanks for your report, your workarounds are interesting.

> sudo usermod -a -G libvirt libvirt-qemu

Users that shall be able to connect to libvirt should be in the group "libvirt" which also is what the socket is on as group.
  srw-rw---- 1 root libvirt 0 Sep 18 12:25 /var/run/libvirt/libvirt-sock=
Now allowing "libvirt-qemu" = the user the guests are executed as to be in that group should only open up a security hole of someone exploiting qemu also being able to reach out to the libvirt service.
Is something else reusing "libvirt-qemu" that shouldn't use it?

> sudo usermod -a -G libvirt libvirtdbus

While I don't think the above is "right" this one is much more interesting.
The user "libvirtdbus" is installed by package bin:libvirt-dbus which is of src:libvirt-dbus.
And indeed it is not member of that libvirt group:
root@f:~# id libvirtdbus
uid=997(libvirtdbus) gid=997(libvirtdbus) groups=997(libvirtdbus)

It might be right that this is a bug on libvirt-dbus which should make it part of the "libvirt" group on it's postinst.
Questions from here:
- Is changing just that group enough to get things working?
  - if not why not, what does adding user libvirt-qemu to group libvirt giving you?
- If we open libvirt to libvirt-dbus "by default" which is what this change would do,
  then how is the access to libvirt-dbus arbitrated?

@mdeslaur - we had non-fun with socket permissions in the past (being too open) so I subscribed you to be aware of the discussion about "what if we let libvirt-dbus access it by default".

@Pitti - are you still on cockpit these days? If so are you (re-)using the libvurt-qemu user in a way I didn't expect? If so could you outline how so we can find a middle ground working fine but being safe?

[Marc Deslauriers (mdeslaur)]

libvirt can be configured in two ways, to use policykit for authentication, or to use traditional unix permissions. Ubuntu uses the traditional permissions configuration, not the policykit one.

libvirt-dbus ships with a /var/lib/polkit-1/localauthority/10-vendor.d/libvirt-dbus.pkla file that contains:

[Allow libvirt-dbus to manage libvirt]
Identity=unix-user:libvirtdbus
Action=org.libvirt.unix.manage
ResultAny=yes
ResultInactive=yes
ResultActive=yes

This allows the libvirtdbus user to manage libvirt. Since we don't use the policykit configuration, this has no effect. The equivalent would be in fact to add the libvirtdbus user to the libvirt group as suggested above.

To prevent unprivileged users from connecting to the libvirt-dbus daemon, it uses a dbus configuration file at /usr/share/dbus-1/system.d/org.libvirt.conf which only allows the root user and members of the libvirt group access to the service.

I have confirmed that adding the libvirtdbus user to the libvirt group as listed above allows the service to function, while blocking unprivileged users from accessing it, so +1 from me.

As for the second configuration change above, adding the libvirt-qemu user to the libvirt group, I am not sure why that is required. Could someone explain why that would be required?

[Chris Routh (routhinator)]

Mark,

Looks like you're correct, removing libvirt-qemu from the libvirt group seems to allow things to work. I also removed the policy from /etc/dbus-1/system.d/ and things kept working after a reboot. Still testing if anything about the system is not working, but seems just adding libvirtdbus to the libvirt group is enough to resolve the access issue.

My apologies. I spent half a day trying to fix this and got sloppy about cleaning up things that didn't change behaviour.

[Chris Routh (routhinator)]

Sorry, meant that last reply for Christian.

[Christian Ehrhardt  (paelzer)]

FYI - this has issues to rebuild (independent to my changes) which stalls providing a test PPA a bit.

[Christian Ehrhardt  (paelzer)]

The PPA build [1] is now complete if someone would want to give it a try.
That should add the libvirtdbus user to the group on install and therefore avoid the issues.

[1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4284

[Christian Ehrhardt  (paelzer)]

Tested on two systems, one with one without the PPA - the fix seems to work just as planned.
This also will be used as SRU Template test steps.

# should install fine
$ sudo apt-get install libvirt-dbus
# should be avail due to dependencies and look normal (as shown here)
$ ls -l /var/run/libvirt/libvirt-sock
srw-rw---- 1 root libvirt 0 Oct 5 05:50 /var/run/libvirt/libvirt-sock
# should be part of the "libvirt" group
$ id libvirtdbus
uid=997(libvirtdbus) gid=997(libvirtdbus) groups=997(libvirtdbus),122(libvirt)
# call should work
$ busctl call org.libvirt /org/libvirt/QEMU org.libvirt.Connect ListDomains u 0

bad:
Call failed: Failed to connect socket to '/var/run/libvirt/libvirt-sock': Permission denied
good:
ao 0

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Christian Ehrhardt  (paelzer)]

Uploaded to groovy.
I also linked another bug as duplicate which is about the same issue.

[Launchpad Janitor (janitor)]

This bug was fixed in the package libvirt-dbus - 1.4.0-1ubuntu1

---------------
libvirt-dbus (1.4.0-1ubuntu1) groovy; urgency=medium

  * d/postinst: add libvirtdbus to group libvirt to be able to access the
    sockets of libvirtd (LP: #1802005)
  * Fix FTFBS due to libvirt 6.6
    - d/p/tests-skip-CPU-pinning-test-on-libvirt-6.6.0.patch
    - d/p/tests-vcpupininfo-use-pytest.skip.patch
    - d/p/tests-vcpupininfo-32bit.patch: fix tests on armhf

 -- Christian Ehrhardt <email address hidden> Tue, 29 Sep 2020 15:16:03 +0200

[Christian Ehrhardt  (paelzer)]

In Focal it is an FTFBS as well, but a different one

=================================== FAILURES ===================================
_______________ TestConnect.test_connect_node_device_create_xml ________________
Fixture "node_device_create" called directly. Fixtures are not meant to be called directly,
but are created automatically when test functions request them as parameters.
See https://docs.pytest.org/en/latest/fixture.html for more information about fixtures, and
https://docs.pytest.org/en/latest/deprecations.html#calling-fixtures-directly about how to update your code.
===================== 1 failed, 33 passed in 4.91 seconds ======================
FAIL test_connect.py (exit status: 1)

That seems to be
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952200

We have the fix for that one in groovy and can cherry-pick it from salsa.

[Christian Ehrhardt  (paelzer)]

Confirmed, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4296 has valid Focal test builds now.

[Christian Ehrhardt  (paelzer)]

Tested on Focal PPA

root@f:~# apt install libvirt-dbus
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  geoip-database libgd3 libgeoip1 libxpm4
Use 'apt autoremove' to remove them.
The following packages will be upgraded:
  libvirt-dbus
1 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.
Need to get 59.9 kB of archives.
After this operation, 9216 B of additional disk space will be used.
Get:1 http://ppa.launchpad.net/ci-train-ppa-service/4296/ubuntu focal/main amd64 libvirt-dbus amd64 1.3.0-1ubuntu1~ppa1 [59.9 kB]
Fetched 59.9 kB in 0s (266 kB/s)
(Reading database ... 76309 files and directories currently installed.)
Preparing to unpack .../libvirt-dbus_1.3.0-1ubuntu1~ppa1_amd64.deb ...
Unpacking libvirt-dbus (1.3.0-1ubuntu1~ppa1) over (1.3.0-1) ...
Setting up libvirt-dbus (1.3.0-1ubuntu1~ppa1) ...
Processing triggers for dbus (1.12.16-2ubuntu2.1) ...
Processing triggers for man-db (2.9.1-1) ...
root@f:~# ls -l /var/run/libvirt/libvirt-sock
srw-rw---- 1 root libvirt 0 Sep 24 13:10 /var/run/libvirt/libvirt-sock
root@f:~# id libvirtdbus
uid=997(libvirtdbus) gid=997(libvirtdbus) groups=997(libvirtdbus),121(libvirt)
root@f:~# busctl call org.libvirt /org/libvirt/QEMU org.libvirt.Connect ListDomains u 0
ao

[Launchpad Janitor (janitor)]

This bug was fixed in the package libvirt-dbus - 1.3.0-1ubuntu1

---------------
libvirt-dbus (1.3.0-1ubuntu1) focal-security; urgency=medium

  * d/postinst: add libvirtdbus to group libvirt to be able to access the
    sockets of libvirtd (LP: #1802005)

 -- Christian Ehrhardt <email address hidden> Tue, 29 Sep 2020 15:16:03 +0200

[Martin Pitt (pitti)]

This regressed in 21.04 (hirsute) again. 1.4.0-2 was synced from Debian (https://launchpad.net/ubuntu/+source/libvirt-dbus/+changelog) instead of merged.

[Christian Ehrhardt  (paelzer)]

Hmmm,
indeed I remember doing a merge for 1.4 in https://launchpad.net/ubuntu/+source/libvirt-dbus/1.4.0-1ubuntu1
I fail to remember to ahve synced it but the logs point at me :-/
Maybe when the FTFBS was fixed we thought that was all that was left ...

I beg your pardon, agree and will fix it again.

[Christian Ehrhardt  (paelzer)]

This would be re-applying the fix and should still work.
Same change as in the past (minus a typo).

Test PPA: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4533

For review please have a look at:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-4533/2021-04-23_10:33:40/hirsute_libvirt-dbus_content.diff

[Christian Ehrhardt  (paelzer)]

If we are on impish by the time we can upload then it would be

[Martin Pitt (pitti)]

Thanks Christian! Lesson learned -- for 21.10 I'll update our images a few weeks *before* the release. (I found a handful of regressions so far..)

[Christian Ehrhardt  (paelzer)]

FYI I'm mostly waiting for impish to open to be able to go on with this.

[Christian Ehrhardt  (paelzer)]

Impish is open, uploaded if there.
Not sure if that is still in some early-cycle-complexity - we will see and SRU it then once complete there.

[Launchpad Janitor (janitor)]

This bug was fixed in the package libvirt-dbus - 1.4.0-2ubuntu1

---------------
libvirt-dbus (1.4.0-2ubuntu1) impish; urgency=medium

  * d/postinst: add libvirtdbus to group libvirt to be able to access the
    sockets of libvirtd (LP: #1802005)

 -- Christian Ehrhardt <email address hidden> Fri, 23 Apr 2021 12:25:41 +0200

[Christian Ehrhardt  (paelzer)]

Ok, Impish is complete and thereby all ready.
I uploaded the very same fix to hirsute for the SRU team to consider.
The SRU template is still present from "last time :-/"

[Brian Murray (brian-murray)]

Hello Martin, or anyone else affected,

Accepted libvirt-dbus into hirsute-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libvirt-dbus/1.4.0-2ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-hirsute to verification-done-hirsute. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-hirsute. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Christian Ehrhardt  (paelzer)]

Old version fails:

root@h:~# apt install libvirt-dbus
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  libvirt-dbus
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 61.6 kB of archives.
After this operation, 350 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu hirsute/universe amd64 libvirt-dbus amd64 1.4.0-2 [61.6 kB]
Fetched 61.6 kB in 0s (275 kB/s)
Selecting previously unselected package libvirt-dbus.
(Reading database ... 48757 files and directories currently installed.)
Preparing to unpack .../libvirt-dbus_1.4.0-2_amd64.deb ...
Unpacking libvirt-dbus (1.4.0-2) ...
Setting up libvirt-dbus (1.4.0-2) ...
Processing triggers for dbus (1.12.20-1ubuntu3) ...
Processing triggers for man-db (2.9.4-2) ...
Scanning processes...

No services need to be restarted.

No containers need to be restarted.

No user sessions are running outdated binaries.
root@h:~# ls -l /var/run/libvirt/libvirt-sock
srw-rw---- 1 root libvirt 0 May 12 06:45 /var/run/libvirt/libvirt-sock
root@h:~# id libvirtdbus
uid=997(libvirtdbus) gid=997(libvirtdbus) groups=997(libvirtdbus)
root@h:~# busctl call org.libvirt /org/libvirt/QEMU org.libvirt.Connect ListDomains u 0
Call failed: Failed to connect socket to '/var/run/libvirt/libvirt-sock': Permission denied

New version in proposed works

root@h:~# apt install libvirt-dbus
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  libvirt-dbus
0 upgraded, 1 newly installed, 0 to remove and 13 not upgraded.
Need to get 63.0 kB of archives.
After this operation, 343 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu hirsute-proposed/universe amd64 libvirt-dbus amd64 1.4.0-2ubuntu0.1 [63.0 kB]
Fetched 63.0 kB in 0s (621 kB/s)
Selecting previously unselected package libvirt-dbus.
(Reading database ... 48757 files and directories currently installed.)
Preparing to unpack .../libvirt-dbus_1.4.0-2ubuntu0.1_amd64.deb ...
Unpacking libvirt-dbus (1.4.0-2ubuntu0.1) ...
Setting up libvirt-dbus (1.4.0-2ubuntu0.1) ...
Processing triggers for dbus (1.12.20-1ubuntu3) ...
Processing triggers for man-db (2.9.4-2) ...
Scanning processes...

No services need to be restarted.

No containers need to be restarted.

No user sessions are running outdated binaries.
root@h:~# id libvirtdbus
uid=997(libvirtdbus) gid=997(libvirtdbus) groups=997(libvirtdbus),120(libvirt)
root@h:~# busctl call org.libvirt /org/libvirt/QEMU org.libvirt.Connect ListDomains u 0
ao 0

[Chris Halse Rogers (raof)]

The verification of the Stable Release Update for libvirt-dbus has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package libvirt-dbus - 1.4.0-2ubuntu0.1

---------------
libvirt-dbus (1.4.0-2ubuntu0.1) hirsute; urgency=medium

  * d/postinst: add libvirtdbus to group libvirt to be able to access the
    sockets of libvirtd (LP: #1802005)

 -- Christian Ehrhardt <email address hidden> Fri, 23 Apr 2021 12:25:41 +0200

[Martin Pitt (pitti)]

This regressed in jammy:

# id libvirtdbus
uid=120(libvirtdbus) gid=125(libvirtdbus) groups=125(libvirtdbus)

This was supposed to be fixed in https://salsa.debian.org/libvirt-team/libvirt-dbus/-/commit/cd5b637db51de64368723996cc770f323b6c1f53 (and hence the package was synced), but this does not work.

This once again completely breaks cockpit-machines. I'll have a closer look, send a fix to Debian, and apply it to jammy.

[Martin Pitt (pitti)]

The image build log shows why:

Setting up libvirt-dbus (1.4.1-1) ...
/var/lib/dpkg/info/libvirt-dbus.postinst: 54: dpkg-vendor: not found

dpkg-vendor is in the "dpkg-dev" package, so it should not be used in postinst scripts. libvirt-dbus could depend on dpkg-dev, but that's highly undesirable. This isn't terribly obvious to fix -- the postinst could do `grep -q ubuntu /usr/lib/os-release`.

But for jammy I'll just take out the condition completely; that's safe, and any derivative will work correctly then.

[1] https://logs-https-frontdoor.apps.ocp.ci.centos.org/logs/image-refresh-3131-20220324-052626/log

[Christian Ehrhardt  (paelzer)]

Thanks a lot Martin!
For the sake of helping your look into this, the old fix in Ubuntu was [1] part of [2].

The two things one might assume to fail are
a) the conditional checks we didn't have before
b) the switch from usermod to adduser

Let me know what you find and if you need help.

[1]: https://git.launchpad.net/~paelzer/ubuntu/+source/libvirt-dbus/commit/?h=lp-1802005-allow-libvirtdbus-to-access-libvirt-GROOVY&id=afd692dfcdc2ab94b1dd5b7f4854cbda496df57f
[2]: https://git.launchpad.net/~paelzer/ubuntu/+source/libvirt-dbus/log/?h=lp-1802005-allow-libvirtdbus-to-access-libvirt-GROOVY

[Martin Pitt (pitti)]

I sent a fix to Debian: https://salsa.debian.org/libvirt-team/libvirt-dbus/-/merge_requests/14

I'll give it a few days, if I can get that landed soon, we can just sync. Otherwise I'll upload it to Jammy directly.

[Martin Pitt (pitti)]

Timeout -- I uploaded the patch of the salsa PR to Jammy now.

[Launchpad Janitor (janitor)]

This bug was fixed in the package libvirt-dbus - 1.4.1-1ubuntu1

---------------
libvirt-dbus (1.4.1-1ubuntu1) jammy; urgency=medium

  * d/postinst: Fix check for Ubuntu. dpkg-vendor lives in dpkg-dev, it cannot
    be used in postinst scripts. Check os-release for "ubuntu" instead, which
    will match "ID=ubuntu" in Ubuntu itself, and "ID_LIKE=ubuntu" in
    derivatives such as Mint. (LP: #1802005)
    See https://salsa.debian.org/libvirt-team/libvirt-dbus/-/merge_requests/14

 -- Martin Pitt <email address hidden> Fri, 01 Apr 2022 06:34:45 +0200