Hi Partick, >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. >This might work, but better check the details with the Cynara team. The key >point is how you define the privilege. You are right. I will check it with Cynara team later. Thanks. Best Regards Zheng Wu >-----Original Message----- >From: Patrick Ohly [mailto:[email protected]] >Sent: Tuesday, September 23, 2014 5:36 PM >To: Zheng, Wu >Cc: [email protected]; Le Foll, Dominique; >[email protected]; Von Dentz, Luiz >Subject: Re: [Dev] FW: Tizen 3 services: use case for multi user > >On Tue, 2014-09-23 at 08:47 +0000, Zheng, Wu wrote: >> Hi Patrick, >> >> >You don't get a list of privileges from Cynara. You ask whether a >> uid >> >+app combination has a certain privilege and get a yes/no answer >> back. >> >What would be the privilege here? It would be your job to define that >> privilege and ensure that Cynara knows who is allowed to have it. >> >> Please check the following the steps and it matches the requirement of >> multi-paired? >> >> 1. each user can run a NTB daemon and NTB daemon will control the >> user's BT agent and paired. > >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)? > >> userB will ask whether a uid+app combination has a certain privilege >> and get a yes/no answer back from Cynara. >> >> If Cynara tell userB that it has a certain privilege to use DeviceR, >> userB will set a mark and use DeviceR. >> If Cynara tell userB that it has not a certain privilege to use >> DeviceR, userB will pair with DeviceR failure and can't use DeviceR >> and tell app that paired with DeviceR failure. > >This might work, but better check the details with the Cynara team. The key >point is how you define the privilege. > >-- >Best Regards, Patrick Ohly > >The content of this message is my personal opinion only and although I am an >employee of Intel, the statements I make here in no way represent Intel's >position on the issue, nor am I authorized to speak on behalf of Intel on this >matter. > > _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
