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

Patrick Ohly patrick.ohly at intel.com
Tue Sep 16 06:51:30 GMT 2014

On Tue, 2014-09-16 at 05:29 +0000, Zhang, Zhengguang wrote:
> 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,

dbus-daemon may be able to do it if you can come up with a suitable
configuration file for your service. It is the job of the D-Bus service
implementer and/or Tizen packager to provide such a file. The default
will be to deny access to untrusted apps.

There will be cases where the expressiveness of a D-Bus policy file is
not sufficient. In those cases, the D-Bus service must provide a policy
file that grants broad access and then call Cynara to implement more
specific checks.

The exact details are work in progress. The corresponding mail thread
has some instructions for evaluating this approach, see

As I said there, now would be a good time to provide feedback.

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.

More information about the Dev mailing list