Bug 1705192
| Summary: | security policy prevents d-feet from accessing bluez | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Olivier Crête <olivier.crete> | ||||
| Component: | dbus-broker | Assignee: | Tom Gundersen <tgunders> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 30 | CC: | daherrma, gilboad, tgunders, yaneti | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2020-02-17 16:39:42 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Olivier Crête
2019-05-01 17:52:04 UTC
Yes, adding a policy to give myself access to bluez seems to have partially fixed bluetooth in gnome. The upstream BlueZ package has this fixed [1]. Unfortunately, there has not been any BlueZ release in almost a year. No idea why they stopped doing releases, they used to be every few months. Maybe we can backport it to Fedora. Regardless, this should not affect current Fedora. Any normal user should have access to BlueZ. Do you run d-feet from a normal user-session? Is your user-ID by any chance smaller than `500`? Lastly, can you show us the log-entry about the denied access? dbus-broker logs a lot of additional information if you look at the verbose journal entries via `journalctl -u dbus-broker -o verbose -b`. [1] https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/src/bluetooth.conf?id=3ef0ce954b66fdf45538a6cdc629f3dac6642832 My user-id is 500 and I did run d-feet from my normal session. But if I read correctly, systemd in Fedora 30 is built to start normal user IDs at 1000. Created attachment 1564471 [details]
journal extract
Here is an extract from the journal, but it's really the at_console policy not working. I guess it's safer to just apply the patch from upstream.
I can confirm that manually patching /etc/dbus-1/system.d/bluetooth.conf, removing the at_console statement and allowing send_destination solves the problem. FWIW my user ID is either 800. (Dragged on, one multiple machines, from Fedora 2...) - Gilboa I discussed this again with the systemd people. The thing is, classic linux splits UIDs into 2 ranges, the system users and the normal users. The split used to be `1-499`, `500-65k`. systemd provides a configuration variable that allows applications to query that split (you can query it from the command-line via `pkg-config --variable=systemuidmax systemd`). At some point Fedora changed this variable from `499` to `999` with the effect that old systems now consider their normal users "system users". These old systems are somehow supported, but it is known that some modern features will not work or just break. The issue now is, with dbus-broker we automatically allow all normal users access to `at-console` policies (e.g., bluetooth access). But since these old systems have their UID as "system users", they will not get this access. Placing a policy into /etc will serve as workaround, with the advantage that you can forget about them when reinstalling the machine (as the UID will then be >1000 anyway). At the same time, the upcoming BlueZ release will fix this as well, since it will make bluez stop using at-console. I am not sure what the best way forward is. This is fixed in BlueZ upstream, and in F31. If this still occurs, please let me know. Thanks a lot for the report! David |