> > > > Or we add the Cynara calls on the service side of the existing APIs, > > which presumably are already organized such that IPC is minimized. I > > would also hope that the services are written in a way that they > > validate incoming data. > > that is indeed another option - assuming it actually is a service and doesnt go > direct to some sqlite db or file. :)
This was (&still is!) actually our plan - to use Cynara in any place where there already is a service. As soon as policy doesn't require popups/asking user each time (hardly the case), the client-side cache of Cynara (that is planned) will minimize the penalty to *no* additional IPC). In some places where there should be a service and there is not, we may want to introduce services, but this is a slightly different task. Also, If application-level API is accessing some resource directly AND there is no way for introducing service (because of any reason from these already mentioned, incl. performance), we have a backup solution, that you can read about in this email thread https://lists.tizen.org/pipermail/dev/2014-April/002543.html In short, this solution is based on standard permissions - no Cynara usage here, just kernel access control + a group per privilege (if we really can't make it any better). This is what Security Manager will handle, apart from Smack rules & labeling of applications. This solution makes popups virtually impossible (since launching popups from application's process can be bypassed and doesn't make sense) but at least app gets access *only* to resources requested in its manifest. BRs, Tomasz _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
