Hi Corentin, >- 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. It can be implemented by lock and unlock.
> 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... How userB would send a request to Cynara with user id and application id params? How to implement it? >userA would be notified... userA would be notified is before userA is disconnected (or userA need to confirm it/ not confirm it ?) or after userA is disconnected? >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. NTB will be modified. So that NTB can run on each user mode and help user manager their obex session and pair and so on. The related source code will be submitted later. Best Regards Zheng WU -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Monday, September 22, 2014 9:40 PM To: Zheng, Wu; Le Foll, Dominique Cc: [email protected] Subject: Re: [Dev] FW: Tizen 3 services: use case for multi user 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
