Hi Zheng Wu,
Please find more details below.
Le 22/09/2014 04:40, Zheng, Wu a écrit :
Hi Dominique,
We still want to clear the Multiuser requirement for NTB.
Can you share the Multiuser requirement for NTB?
Such as multi-paring, multi-adapter and so on.
As per https://wiki.tizen.org/wiki/Multi-user_Bluetooth, multi-user
requirements are :
- multi-pairing : several users can be paired on the same remote device
but each one has to be distinctly authentificated.
- multi-connections :
1st phase: when userA is connected to a device, userB can't connect
to the same device.
2nd phase : when userA is connected to a device, userB can connect
to other services on the same device.
- adapter multi-control : when userA is connected to a device, userB can
not modify adapter property (turn OFF bluetooth, change adapter name or
visibility) at the same time.
If userB needs some privileges to be allowed to do that.
Actually this part is linked to the security. following our
example, when userB will request to turn OFF bluetooth, that would send
a request to Cynara with user id and application id params.
Then userB will be granted or not to turn OFF bluetooth. If
userB is authorized to turn OFF bluetooth while userA is connected,
userA would be notified...
This test case is not the priority for now.
At current, NTB run on app mode not root mode, so we need to design the related
solution depend on it.
This is a multi-user compliance issue. 'app' user is a predefined user
(single user mode) that is not supposed to exist in the future
(multi-user mode)...
In addition in that current state, only 'app' user can launch obexd. We
would expect that every logged users could start an obex session.
NTB could run on a dedicated bluetooth user, as it is the case with
weston and its dedicated 'display' user.
Then real users would have to manage their own obex session.
1. For multi-paring, can you share your idea for Luiz's and martin's comment.
(in the following mail)
I posted a use case below.
2. For adapter multi-control, we want to use a lock to implement it.
(userA and userB)
once userA uses bluetooth, he set a lock on the adapter and userB can't use
bluetooth.
After userA uses bluetooth, he will unlock it and userB can use bluetooth.
A lock might be a good thing to handle concurrent accesses to the same
adapter, but all users have the same privileges in this solution.
We need a policy based on user privileges. Plz see above.
We will use the solution to implement adapter multi-control.
(Please check the following mail too).
Best Regards
Zheng Wu
-----Original Message-----
From: Xu, Martin
Sent: Wednesday, September 10, 2014 3:30 AM
To: Von Dentz, Luiz; Ohly, Patrick
Cc: [email protected]; Zheng, Wu
Subject: RE: [Dev] Tizen 3 services: use case for multi user
Hi:
-----Original Message-----
From: Dev [mailto:[email protected]] On Behalf Of Von Dentz,
Luiz
Sent: Friday, September 05, 2014 1:01
To: Ohly, Patrick
Cc: [email protected]
Subject: Re: [Dev] Tizen 3 services: use case for multi user
Hi Patrick,
'UserA requests to pair with DeviceR
an authentication popup appears on UserA default screen (from DeviceL)
and DeviceR allowing pairing UserB requests to pair with Device an
authentication popup appears on UserB default screen (from DeviceL)
and DeviceR allowing pairing UserA and UserB are paired with DeviceR'
I agree with Luiz's comments, the paring is based on device not user for
Bluetooth.
Yes, but it could be implemented in NTB or BlueZ...
And I think the reason why we want to support multi-paring is just to protect
the
personal date for PBAP, MAP and so on, which is our second request.
BlueZ 5 persistently pairs remote devices, which brings up a use case
for multi-pairing :
UserA is paired and connected to deviceR. When userA is disconnected
from deviceR, userA stays paired.
In such case, a new user (userB) logins to the system and he is
automaticaly paired to deviceR without any authentication.
As userB is already paired with the remote deviceR, he can just connect
to PBAP service from deviceR to retrieve the phonebook for example.
However, PBAP, MAP, FTP, OPP are all based on OBexd, and run at normal user
privilege not root, and each has it's own default home directory bound with the
user to share the data through Bluetooth.
So that means for above profiles, the multi-user are supported natively.
We just did not try and verify the scenario before, but I think it will not big
issue
here, we will have a try on it.
So as to adapter multi-control, I think that requirement is reasonable. We can
try to add a lock to each adapter at NTB, so normal user needs to acquire the
lock before accessing it,(release the lock after the adapter is not be used
anymore), that will not break current framework in NTB and BlueZ and
implement the features.
Any comments?
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
Best regards,
Corentin
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
