Support for user-based and seat-based device restrictions (multi-user and multi-seat)

[troyrollo]

While bluez seems (not unreasonably, having regard to the way pairing works) to be designed to share devices on a systemwide basis, there are times when devices should be restricted to a particular user or seat. Most often, based on Google searches, this seems to arise with bluetooth headsets, but it could also arise with other devices such as bluetooth connections between a desktop and a tablet or phone.

While this could be addressed (on a cooperative basis) on the client side, it seems that this is at times a security issue which ought to be dealt with in the daemon so that only authorised users can even see the device.

I see a number of possible approaches to this, but it seems to me that the client that initiates or confirms a pairing request should have the opportunity to become the "owner" of the device so that they can then determine who else gets to see / use the device. The owner can then determine whether other users can see it (and ideally, which users).

I have the following ideas on this:

1. On Unix/Linux systems, the client could be identified by GetConnectionUnixUser. However, that would restrict the functionality to those systems.
2. On any system, the client could be identified by a magic cookie. This would give some flexibility to clients to share magic cookies to enable sharing of access, or for each client to have multiple magic cookies (for example, one "user" cookie, and multiple "user+seat" cookies", with a client making queries able to include multiple cookies) and for the system to be portable to different platforms. The drawback of this approach is that it requires every client that wishes to query, access or use a restricted device to be cookie aware.
3. It seems that once a user has access to a device, there is no way for the daemon to securely identify the seat on which client is, so seat-restrictions would, to some extent, need to be on a co-operative basis.
4. There would, it seems to me, be some utility in being able to associate generic named properties with a device so that, for example, co-operative seat-restrictions could be implemented by a client-based protocol.

Is there an appetite to add support for features of this kind into bluez? If so, is there a preferred approach to doing so?

[Vudentz]

@troyrollo Bluetooth pairing cannot distinct users though, so for the remote device once you are paired it is paired to the system not to specific user/seat. We could something for LE only which is to use seat specific identity address (instead of using the public address switch to seat specific random static address), but this would not work for Classic since that only support the usage of public addresses.

That said perhaps we could adopt something like, if I recall correctly, the likes of NetworkManager do that allows the user to select if the access point shall be stored system-wide or not, noting that it will come with the same limitations as not being able to use the device.

Anyway, regardless of the solution I think it won't be very simple therefore it is hard for upstream to commit to dedicate resources working on it as it is a very niche feature.