Le 12/05/2014 16:51, Xu, Martin a écrit :
Hi:
Does that mean for every API involved in the huge list on the page above we
intend to create a new wrapping middleware component to add the security
checks and other "added value"?
One of effort in NTB is to split the security checking out.
In fact, Samsung originally do that at the initial version of Bluetooth
framework.
Later, after F2F meeting at Helsinki (Samsung, Comms upstream/Tizen, Smack
team), we agree that that can be handle at Smack.
Someone can educate me what is the security check here, thanks!
As described in
https://www.tizen.org/privilege/tizen
When an App is installed its privileges are stored in the privilege DB
(soon with the extra information: user only, or any user).
When the App is executed an request for a service, we need to enforce
the respect of the declared manifest.
We cannot trust the App itself to enforce the respect of the manifest
and so the system must do it.
The detail level of these manifest are quite fine. e.g. for Bluetooth
you have one privilege for each BT profiles.
Each App has potentially different manifest.
Enforcing manifest respect via Smack was not very sucessfull in Tizen
2.2 and so we have been looking to an alternative model.
Furthermore when moving from the legacy WRT to Crosswalk, we benefit of
an optimisation, having a single Web process for all App, which would
have made the enforcement via Smack even more complex than in Tizen 2.2.
Dominig
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
