- 1 Introduction
- 2 phase 1 : user isolation
- 3 phase 2 : shared-pairing with exclusive connection
- 4 phase 3 : shared-pairing with parallel connections
- 5 phase 4 : local adapter control
- 6 phase 5 : sharing devices
- 7 a note about user privileges
- 8 Links
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
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.
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.
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.
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: https://wiki.tizen.org/wiki/Security/Overview#The_privileges
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.