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
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
