Hi doming, Thanks for your suggestions.
1. According to your suggestion, We can work together to try to implement the mini BT requirements of multi-user(multi user pairing) before NTB is merged to tizen.org. 2. Next step, we will continue to implement the BT remained requirements of multi-user(such as multi-user pairing 2st, multi-user connections, adapter multi-user control) after NTB is merged to tizen.org. In fact, some requirements of multi-user connections can be matched by the current NTB(Bluez and Obexd) solution. 3. And If we can limit access to the BlueZ signaling (pairing, connection, ...), multi-user connections, adapter multi-user control can be implemented too. It is our plan. Thanks. Best Regards Zheng Wu -----Original Message----- From: Dominig ar Foll (Intel OTC) [mailto:[email protected]] Sent: Tuesday, September 23, 2014 8:42 PM To: Zheng, Wu Cc: [email protected] Subject: Re: [Dev] FW: FW: Tizen 3 services: use case for multi user Zhang if we we run NTB as a special user (e.g. bluetooth), then we can limit any transport creation access via BlueZ control to that privilege user. Once that we can limit the creation of the transport pipe, then OBEX (or other transport) can be use by the user. The challenge is to limit access to the BlueZ signaling (pairing, connection, ...), there is no real need to control the transport much after that. Just need to "only" give the access right to a given App for a given user) what can be done with a smack rule at the creation of the connection. Dominig ar Foll Senior Software Architect Open Source Technology Centre Intel SSG Le 23/09/2014 12:40, Zheng, Wu a écrit : > Hi Dominig, > > Thanks for your suggestions. > > Just OBEXD run on each user mode, NTB need to manage and control the related > features of OBEXD(such as pbap, opp and so on). > It is why NTB need to run on each user mode. > > NTB run on each user mode(such as userA and userB) with privilege, can NTB > stop ogue user to access the lower level directly? > Thanks. > > Some suggestions? > > Best Regards > Zheng Wu > > -----Original Message----- > From: Dev [mailto:[email protected]] On Behalf Of Dominig ar > Foll (Intel OTC) > Sent: Tuesday, September 23, 2014 6:29 PM > To: [email protected] > Subject: Re: [Dev] FW: FW: Tizen 3 services: use case for multi user > > Hello, > > the easiest implementation is to run only one NTB deamon with privilege and > to get the user to pass their request via the daemon. > With that model we can stop rogue user to access the lower level directly and > NTB can implement the multiuser policy. > > Dominig ar Foll > Senior Software Architect > Open Source Technology Centre > Intel SSG > > Le 23/09/2014 12:01, Patrick Ohly a écrit : >> On Tue, 2014-09-23 at 09:53 +0000, Zheng, Wu wrote: >>>> What prevents a rogue user process from ignoring NTB and using >>>> obexd and/or the system's Bluetooth support directly (i.e. >>>> replicate obexd inside the process itself)? >>> It need to be analyzed cases by cases. >> If you don't know, then check it first. If it turns out to be >> impossible, then it might not be worth implementing access control in >> NTB at all because it will have to be done again elsewhere (kernel?). >> >> Even if it turns out to be feasible, then it cannot be turned on >> without first ensuring that all uses of Bluetooth go through NTB. >> > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
