| Summary: | sys-apps/dbus-1.12.12-r1 breaks bluez for user out of plugdev group without systemd | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Ondrej Caletka <ondrej> |
| Component: | Current packages | Assignee: | Pacho Ramos <pacho> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | asturm, dflogeras2, freedesktop-bugs, marci_r |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| URL: | https://www.spinics.net/lists/linux-bluetooth/msg77610.html | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
emerge --info
re-enable obsoleted feature |
||
Seems to work fine for me: $ bluetoothctl list Controller 00:1E:0A:00:01:DD BlueZ 5.50 [default] I've upgraded back to version 1.12.12-r1 and the problem is back again: $ bluetoothctl list # bluetoothctl list Controller 60:F6:77:B3:E6:7D pes [default] Running dbus-monitor, I see message being rejected. # dbus-monitor --system … method call time=1551360513.830695 sender=:1.78 -> destination=org.bluez serial=7 path=/; interface=org.freedesktop.DBus.ObjectManager; member=GetManagedObjects error time=1551360513.830722 sender=org.freedesktop.DBus -> destination=:1.78 error_name=org.freedesktop.DBus.Error.AccessDenied reply_serial=7 string "Rejected send message, 2 matched rules; type="method_call", sender=":1.78" (uid=1000 pid=15912 comm="bluetoothctl list " label="kernel") interface="org.freedesktop.DBus.ObjectManager" member="GetManagedObjects" error name="(unset)" requested_reply="0" destination="org.bluez" (uid=0 pid=8814 comm="/usr/libexec/bluetooth/bluetoothd " label="kernel")" method call time=1551360513.831399 sender=:1.78 -> destination=org.freedesktop.DBus serial=8 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RemoveMatch string "type='signal',sender='org.bluez',path_namespace='/org/bluez'" method return time=1551360513.831444 sender=org.freedesktop.DBus -> destination=:1.78 serial=9 reply_serial=8 method call time=1551360513.831455 sender=:1.78 -> destination=org.freedesktop.DBus serial=9 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RemoveMatch string "type='signal',sender='org.bluez',path='/',interface='org.freedesktop.DBus.ObjectManager',member='InterfacesAdded'" method return time=1551360513.831472 sender=org.freedesktop.DBus -> destination=:1.78 serial=10 reply_serial=9 Is there anything else I can try to troubleshoot it? i'am expecting the same Problems.
After Update from sys-apps/dbus-1.10.24 to 1.12.12-r1 i cant use bluetoothctl.
as normal user open bluetoothctl, as root /etc/init.d/bluetooth restart.
[bluetooth]# list
Controller 34:E1:2D:1F:E8:79 mobile-hq-x [default]
[bluetooth]# power on
Failed to set power on: org.freedesktop.DBus.Error.AccessDenied
without restart bluetoothctl returns cant find any controller.
using default/linux/amd64/17.0/desktop profile, no systemd
[I] sys-apps/dbus
Verfügbare Versionen: 1.10.18^t 1.10.24 [m]1.12.12-r1 {X debug doc elogind selinux static-libs systemd test user-session ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32" KERNEL="linux"}
Installierte Versionen: 1.10.24(23:38:50 04.03.2019)(X -debug -doc -elogind -selinux -static-libs -systemd -test -user-session ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="32 64 -x32" KERNEL="linux")
Startseite: https://dbus.freedesktop.org/
Beschreibung: A message bus system, a simple way for applications to talk to each other
at least with systemd running it works fine for me. If you are not using systemd, maybe you will need to be in plugdev group (In reply to Pacho Ramos from comment #4) > at least with systemd running it works fine for me. If you are not using > systemd, maybe you will need to be in plugdev group Being in plugdev group does not help (AFAIK, you don't have to be in any group, as long as you have a session on the console). My guess is that the D-Bus policy file /etc/dbus-1/system.d/bluetooth.conf is not interpreted properly by the new version of D-Bus on an openrc system. I ran into this also. Downgrading dbus worked around it for me. I run openrc on all my systems, but I only seemed to be affected on this laptop which uses Intel bluetooth. I'll test others next week when I'm back home; this is the only system I use bluetooth heavily. After looking a bit at my other systems, it seems that only one can use bluetooth as a normal user. One big difference is that on the working machine, I rebuilt @world (from the recent gcc-8 upgrade) _after_ the dbus-1.12.12-r1 upgrade. So my wild-guess theory at the moment is that perhaps it works because all my packages were rebuilt with dbus-1.12, where my non working machines went to dbus-1.12 _after_ having rebuilt the world. So to try to prove this theory, on one of the broken machines, I tried rebuilding bluez, and consolekit. This didn't fix it, but are there maybe other packages I should rebuild to prove/disprove this theory? pam maybe? I don't pretend to understand fully the login session workflow. Created attachment 571020 [details]
re-enable obsoleted feature
I also lost connectivity to the bt headset after the last reboot.
Apparently dbus depends on an obsoleted features to detect the at_console, the dbus news file also says such feature is scheduled to be removed completely in future releases..
Alternatively as an even quicker workaround it's enough to change /etc/dbus-1/system.d/bluetooth.conf and replace root in <policy user="root"> with the user that should connects to bluez.
Thanks Andrea, that patch worked here on one of my affected systems. I still cannot explain what's different on the system that 'just worked' after upgrading. It certainly doesn't have your patch applied. (In reply to Andrea from comment #8) > > Apparently dbus depends on an obsoleted features to detect the at_console, > the dbus news file also says such feature is scheduled to be removed > completely in future releases.. Thank you! More context on this can be found here: https://www.spinics.net/lists/linux-bluetooth/msg75267.html There's also patch in upstream Bluez, that addresses the issue and basically allow any user to do anything with Bluetooth: https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/src/bluetooth.conf?id=3ef0ce954b66fdf45538a6cdc629f3dac6642832 Since it has not been released yet, maybe we could backport this patch into net-wireless/bluez-5.50-r2 so bluetooth works even after dbus update. Contrary to my previous statement: (In reply to Ondrej Caletka from comment #5) > (In reply to Pacho Ramos from comment #4) > > at least with systemd running it works fine for me. If you are not using > > systemd, maybe you will need to be in plugdev group > > Being in plugdev group does not help (AFAIK, you don't have to be in any > group, as long as you have a session on the console). My guess is that the > D-Bus policy file /etc/dbus-1/system.d/bluetooth.conf is not interpreted > properly by the new version of D-Bus on an openrc system. Being in plugdev group actually works around the issue now. I probably didn't kill the dbus daemon after joining the group, which led to false statement above. @pacho, do you think we should do something here, like backporting the upstream patch? It would make plugdev group for bluetooth obsolete and should be more future-proof than trying to fix dbus for a deprecated feature. Personally I would wait for the next bluez release for including this change. The ebuild is already suggesting non-systemd people to be in plugdev group, and for this change in policy I think it would be better to wait for a new upstream release to ensure there is no side effect (I am a bit unsure about allowing all the users to handle bluetooth devices freely... if upstream finally makes a release with this change, perfect, but meantime, I would wait a bit more). I also prefer to completely transition away from plugdev group in that new release than doing it on a small revision The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d0fe48785cce688dd6838794c810a3786c1bc1ef commit d0fe48785cce688dd6838794c810a3786c1bc1ef Author: Pacho Ramos <pacho@gentoo.org> AuthorDate: 2019-06-10 11:22:54 +0000 Commit: Pacho Ramos <pacho@gentoo.org> CommitDate: 2019-06-10 11:22:54 +0000 net-wireless/bluez: Backport lots of fixes (from Fedora)... - Include multiple fixes backported by Fedora people - Stop relying on plugdev group and follow upstream policy (#679034) - Update udevadm PATH for current systemd (#539844) - Rename USE alsa to midi (#658862) Closes: https://bugs.gentoo.org/679034 Closes: https://bugs.gentoo.org/658862 Bug: https://bugs.gentoo.org/539844 Package-Manager: Portage-2.3.67, Repoman-2.3.13 Signed-off-by: Pacho Ramos <pacho@gentoo.org> net-wireless/bluez/Manifest | 1 + net-wireless/bluez/bluez-5.50-r3.ebuild | 267 +++++++++++++++++++++ .../bluez/files/bluez-5.50-sink-connect.patch | 72 ++++++ .../bluez/files/bluez-udevadm-path-r1.patch | 10 + net-wireless/bluez/metadata.xml | 9 +- 5 files changed, 354 insertions(+), 5 deletions(-) The 5.50-r3 bump did not resolve the issue for me. I logged out, restarted dbus, and reloaded udev as well, but still no devices are present in bluetoothctl or plasma. Cancel my last, I was being all kinds of stupid. It works as advertised, thanks! |
Created attachment 566878 [details] emerge --info After updating sys-apps/dbus from 1.10.24 to 1.12.12-r1, bluetooth subsystem stops working for regular user – the "list" command in "bluetoothctl" says "No controller found", KDE Plasma widget disappears and in the settings, it claims the same. Bluetoothctl however works correctly for the root user. The D-Bus policy file /etc/dbus-1/system.d/bluetooth.conf installed by Bluez is unaltered. Downgrading D-Bus to 1.10.24 works around the issue.