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 (this is from a previous report elsewhere and partly reflect earlier thinking - I have noted changes in my thinking in square brackets):
- On Unix/Linux systems, the client could be identified by
GetConnectionUnixUser. However, that would restrict the
functionality to those systems [this would not seem to be a
problem as it seems bluez is restricted to Linux anyway]
- [this would seem not to be necessary given the Linux restriction] 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.
- 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 [it *might* be possible to do so using GetConnectionUnixProcessID, sd_pid_get_session, and sd_session_get_seat, but I suspect that processes started with systemctl --user, like wireplumber, might mess that up, since it seems they are not part of a session - the comment to sd_pid_get_session in sd-login.h seems to point to this problem, suggesting that the best that could be done is to use GetConnectionUnixUser and sd_uid_get_seats].
- 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?
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
