[Dev] Tizen 3 services: use case for multi user

Dominig ar Foll (Intel OTC) dominig.arfoll at fridu.net
Tue Sep 16 08:51:10 GMT 2014


Dominig ar Foll
Senior Software Architect
Open Source Technology Centre
Intel SSG

Le 16/09/2014 07:29, Zhang, Zhengguang a écrit :
> Hi, Domonique
>   
>> Le 09/09/2014 22:30, Xu, Martin a écrit :
>>
>>> So as to Winet request,
>>> 1. multi-configuration, we can also add a lock at Winet to implement that
>> easily.
>> Great if it"s easy it should be quick.
>> When will we see it ?
>>> 2. credentials, I think the best way is to add a user check at auto-reconnect
>> of ConnMan, that is the best way to implement the feature, we can try to
>> work out the patches.
>>> Thanks!
>> You need to check with Conmann that they are willing to do that in their
>> upstream project and find an alternative would they refuse.
>> Please check ASAP in order to confirm if your idea is viable or nor.
>>
> We are now working on the multi-user solution design in WiNet subsystem and I have some questions about it, could you please help me to clarify them? Thanks in advance!
> 1.  We know that for tizen 3.0 multi-user and security solution, some will be implemented in dbus, some needs to be done in subsystem, could you please help me to confirm what needs to be done in subsystem? My understanding is that dbus will handle security, and multi-user conflict management needs to be handled in subsystem, is it right?
The work done on D-bus will allow to integrate Cynara in the D-Bus 
policy check.
When the authorisation requests integrated in the Manifest are mapped on 
unique D-bus request, that will allow to get the security check done by 
D-bus almost out of the box.
If the Mapping is more convoluted then you will need to implement the 
check at a higher level.

For multiuser and resource management which is not controlled by Cynara, 
the Cynara integration with D-bus will not provide any help.
If the service under D-Bus is multi user aware, you are good to go, if 
not you need to implement the control at a higher level.

In the particular case of WiNet, the immediate issue is about the 
requirement to isolate user credentials for network access (either via 
WiFi or Tethering). As far as I know that is done neither by Conmann nor 
by BlueZ.
So a higher level implementation is required (e.g. in your daemon).


> 2. 	By our investigation about the WiNet multi-user requirement wiki, we propose to implement it in ConnMan, which is supposed to be the minimal modification for us, and if this solution is acceptable, we don't plan to submit the related ConnMan patches to upstream, but only maintain them in Tizen ConnMan, for it is not a common requirement for ConnMan upstream. Any suggestions about it, please also let me know.
If you succeed to to get the multi user management integrated in Conmann 
in the upstream project, it's a valid option, if not (which more likely) 
it is not.
Creating a bespoke version of Conmann for Tizen would not be acceptable. 
In that case you would need to implement at higher level (once again, as 
you already have a privilege daemon, it would be logical to put it there).

I honestly do not see any other valid option to respect Tizen 3 timing 
than to implement the check in your WiNet daemon. You can in parallel 
start a thread with Conmann community to see how you could implement 
these extra validation in the upstream project. But that will be a long 
effort without any guarantee of success.

Dominig


More information about the Dev mailing list