Any user can manage bluetooth devices

Bug #297635 reported by Dominik
6
Affects Status Importance Assigned to Milestone
bluez (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: bluez-gnome

This is on Ubuntu 8.10. Using the new Guest session I can manage bluetooth devices, e.g. delete them, and the change impacts other users on the system.

Steps to replicate:
1. Log in as guest.
2. Go to System -> Preferences -> Bluetooth
3. Pair with a new device or delete an existing device.
4. Log out and log in with a regular user. The device list is changed!

Expected behaviour:
1. The Guest user should not be able to delete bluetooth devices added by other users!
2. Potentially, bluetooth devices added by the Guest user should not be added for other users as well and/or retained after the Guest user has logged out.

Possible solution:
Create a system-wide bluetooth device/settings list and per-user bluetooth device/settings lists. This way system-critical bluetooth devices can be available to all users (e.g. mouse and keyboard), but can only be added/deleted by root (and any device could be marked as such directly from the bluetooth panel by giving the sudo password), and each user has their own bluetooth devices which they can add/delete at will. This way any bluetooth devices added by Guest would be erased after they log out and would not show up for other users at all.

This "per user" behavour would be expected from an application which can be run by any user without giving the sudo/root password.

Maybe I should report this directly to the maintainers of bluez-gnome as well?

Revision history for this message
Chris Coulson (chrisccoulson) wrote :

I can confirm this, but I don't know if it's a bluez bug or whether it can be fixed in gdm-guest-session.

Martin - what do you think?

Revision history for this message
Martin Pitt (pitti) wrote :

Can someone please give me a quick heads-up how BT devices are currently managed? Sorry, I have approximately zero knowledge about BT :(

My feeling is that BT devices should be tied to an user session, just like USB sticks, digicams, etc. I. e. whoever has the current foreground session "owns" the device which gets plugged in/paired. This works well for USB devices because each of them has its own /dev/bus/usb/... device node; so BT devices don't?

Revision history for this message
Chris Coulson (chrisccoulson) wrote :

I'm not familiar with how BT devices are managed either, but from what I've seen on my system, BT devices are not tied to any particular user session. BT devices are system wide and appear to be managed from the applet by communicating with bluetoothd over the system bus, and bluetoothd appears to enforce no access controls with this.

So, I think that this is a bluez issue Martin

summary: - [Intrepid] Guest user can manage bluetooth devices
+ Guest user can manage bluetooth devices
summary: - Guest user can manage bluetooth devices
+ Any user can manage bluetooth devices
Revision history for this message
Baptiste Mille-Mathias (bmillemathias) wrote :

Sorry to paste dbus conf from bluetooth:
-----8<-------------------------------------------------------
  <policy user="root">
    <allow own="org.bluez"/>
    <allow send_destination="org.bluez"/>
    <!-- allow root to send to agents -->
    <allow send_interface="org.bluez.Agent"/>
  </policy>
  <!-- allow users at the console, see consolekit or libpam-foreground -->
  <policy at_console="true">
    <allow send_destination="org.bluez"/>
  </policy>
  <!-- allow users of netdev group to communicate with hcid -->
  <policy group="netdev">
    <allow send_destination="org.bluez"/>
  </policy>
  <!-- allow users of lp group (printing subsystem) to communicate with hcid -->
  <policy group="lp">
    <allow send_destination="org.bluez"/>
  </policy>
  <policy context="default">
    <deny send_destination="org.bluez"/>
  </policy>
-----8<-------------------------------------------------------
but there is some kind of restrictions (perhaps it could be enhanced).

Should we do special casing for guess user ?

Revision history for this message
Martin Pitt (pitti) wrote :

Baptiste,

I think the D-BUS configuration is alright. We certainly don't want to remove at_console, this would break it for any normal user, too.

What we could do is to have bluez use PolicyKit instead of just relying on the very coarse at_console D-BUS policy. Then we can remove the bluez privileges for the guest session.

Revision history for this message
Chris Coulson (chrisccoulson) wrote :

TBH, bluez should probably provide the concept of system and user connections much like network manager does

papukaija (papukaija)
tags: added: intrepid
tags: added: bluez-classic
Revision history for this message
Konrad Zapałowicz (kzapalowicz) wrote :

This is reported against an old version of Ubuntu and many things has changed since then. Because of that we won't fix this issue however if this behavior repeats on a modern version please fill a bug report against it and we will take it from there.

Changed in bluez (Ubuntu):
status: New → Invalid
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.