Multi-user Bluetooth

From Tizen Wiki
Jump to: navigation, search


Tizen requires a multi-user Bluetooth feature.

Bluetooth is commonly managed at the system level. Multi-user support consists of having several users managing bluetooth independently.

At the moment BlueZ doesn't manage bluetooth pairing and connections per user but only per system. So Tizen needs a multi-user policy applied between Tizen bluetooth C API and BlueZ. Tizen must enforce any user to use the service as intended (e.g. by blocking any undesired direct access to BlueZ)

The main principle is to let a user controlling his bluetooth connection to a remote device.

This bluetooth connection should NOT be accessible from other users

To ease bluetooth multi-user integration into Tizen, let's split this task into different phases ordered by priority.

  • phase 1 : user isolation
  • phase 2 : shared-pairing with exclusive connections
  • phase 3 : shared-pairing with parallel connections
  • phase 4 : local adapter control
  • phase 5 : shared devices

Before describing those bluetooth multi-user cases, we can consider :

  • 2 users : UserA and UserB,
  • who share a single local device : deviceL
  • communicating with a remote device : DeviceR

phase 1 : user isolation

Bt multiuser phase1.jpg

Context: userA is paired and connected to deviceR1.

  • Ensure that userB can NOT benefit from the pairing link between deviceL and deviceR initiated by userA
  • userA owns the deviceR1 connection. userB can NOT connect to deviceR1
  • userB can pair and connect to deviceR2

The main point is to always protect deviceR's private data from a user to another user.

pairing request entrance

When a Tizen device receives a pairing request, we can not know which user is addressed. I suggest that the 1st Privilege user connected on the device receives the popup in his display and decides to accept or reject the pairing request.

A Privilege user is a user that has special right (e.g. to install global App). The first user created on a system is always privileged

It can be verified using tzplatform_has_system_group(uid_t uid) API from libtzplatform-config component.

see Multi-user Tizen-platform-config

obex test cases

howto send a file ( opp client side )

When userA wants to send a file to deviceR :

  • userA verifies that he is paired himself with deviceR. This is done by asking this to NTB daemon.
  • userA requests to send a file to deviceR. NTB daemon, running as 'bluetooth' user, ensures that the file to send is owned by userA. userA can not send a file from a userB directory.

howto receive a file ( opp server side )

When a Tizen device receives a file :

 NTB daemon checks if a user is already paired with the device who initiates the file transfer.
   |_ if no, NTB daemon rejects the file transfer.
   |_ if yes, NTB daemon checks if the paired user is logged.
      |_ if no, NTB daemon rejects the file transfer.
      |_ if yes, a popup appears on the targeted user display.
         |_ targeted user rejects the file.
         |_ targeted user accepts the file. The file is received in a "bluetooth" user private directory, then moved to a user private directory.

As obexd is run as 'bluetooth' user, the file is received in a 'bluetooth' user private directory. Then NTB daemon should call security-manager to move the file to a targeted user directory and set user ownership and permissions to it.

phase 2 : shared-pairing with exclusive connection

Bt multiuser phase2.jpg

Context: if userA is a Privilege user and requests to pair with deviceR.

  • userA can decide to share the pairing link with userB
  • userB can NOT connect to deviceR whatever the profile

The Privilege user feature integration is progressing in Tizen Application FW. There will be a communication about that.

phase 3 : shared-pairing with parallel connections

Bt multiuser phase3.jpg

Context: userA and userB shares the pairing link and userA is connected to a deviceR's profile.

  • userB can NOT benefit from the userA's opened connection
  • userB can connect to other profiles

That requires to know if some data are shared between profiles in a device.

Needs deeper investigations to know if this case makes sense in reality.

May some profile categories would be the solution.

phase 4 : local adapter control

  • if userB is a Privilege user, he can do some local adapter property changes (i.e. turn off bluetooth or modify adapter name).
  • if userB is a common user, he can NOT do such actions on local adapter.

phase 5 : sharing devices

We can imagine that some shared devices could be used by every users or be considered as a system device.

For example, a bluetooth remote control could be associated to the system.

a note about user privileges

Security privileges and multi-user features are different topics.

Multi-user aims to protect user from other user, whereas security privilege aims to protect actions from user.

Privileges are presented here:

In the above multi-user phases description, we always consider that userA and userB have previously checked they have relevant privileges to make pairing and connections requests.