no adapter found on second seat [loginctl multiseat]

Bug #2033324 reported by Christian Pernegger
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gnome-bluetooth (Ubuntu)
New
Undecided
Unassigned

Bug Description

I've set up a second seat via loginctl --attach, resulting in the following udev rules:

TAG=="seat", ENV{ID_FOR_SEAT}=="drm-pci-0000_6e_00_0", ENV{ID_SEAT}="seat1"
TAG=="seat", ENV{ID_FOR_SEAT}=="input-pci-0000_6c_00_0-usb-0_11_1_0", ENV{ID_SEAT}="seat1"
TAG=="seat", ENV{ID_FOR_SEAT}=="sound-pci-0000_6e_00_1", ENV{ID_SEAT}="seat1"
TAG=="seat", ENV{ID_FOR_SEAT}=="usb-pci-0000_6e_00_3-usb-0_1", ENV{ID_SEAT}="seat1"

(Since loginctl doesn't consider BT adapters per-seat--they don't show up in loginctl seat-status at all--adding an extra one and assigning it to seat1 does accomplish nothing.)

However, when logged in on seat1 the GNOME BT settings panel insists there's no BT adapter attached.

Funnily enough
- the top-right drop-down menu shows (some?) connected devices
- opening the BT settings panel triggers something alright (as seen in bluetoothctl)

If a BT adapter is not a per-seat resource then I'd expect it to be configurable by (authorised) users no matter what seat they log in on.

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: gnome-bluetooth 3.34.5-8
Uname: Linux 6.4.12-060412-generic x86_64
ApportVersion: 2.20.11-0ubuntu82.5
Architecture: amd64
CasperMD5CheckResult: pass
Date: Tue Aug 29 00:22:00 2023
InstallationDate: Installed on 2023-08-25 (3 days ago)
InstallationMedia: Ubuntu 22.04.3 LTS "Jammy Jellyfish" - Release amd64 (20230807.2)
SourcePackage: gnome-bluetooth
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Christian Pernegger (fallenguru) wrote :
Revision history for this message
Christian Pernegger (fallenguru) wrote (last edit ):

Found the cause:

gsd-rfkill[2049]: Could not open rfkill device: Could not open RFKILL control device, please verify your installation

GNOME's BT GUI needs access to /dev/rfkill to work. It's tagged "uaccess" in udev, so in theory all logged-in users should get access via an ACL, but in practice this doesn't seem to work for seats other than seat0 in a multiseat scenario.

Removing the "seat" tag and re-adding the "shared" tag via custom udev rule doesn't help--the acl doesn't get added if you don't login on seat0.

Of course simply changing the permissions to 666 and starting /usr/libexec/gsd-rfkill manually does the trick until the next reboot, but ...

So, not a gnome-bluetooth* bug, nor a gnome-control-center one, but whose is it? Logind? /dev/rfkill should be available to all users logged in locally, IMHO.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.