[Dev] Understanding Cynara scope.

Rafał Krypa r.krypa at samsung.com
Tue May 13 12:11:55 GMT 2014


On 2014-05-13 11:36, Counihan, Tom wrote:
>
> Hi Folks,
>
>  
>
> Reading all the extensive traffic on the topic, I come away with a vision of the Cynara scope.
>
> I would like to ask the question to get it validated.
>
>  
>
> Is Cynara’s exclusive goal to service ‘downloadable’ Web applications from an ‘app store’?
>

Let me try to answer that question.
The main purpose for Cynara is to implement user space access control between downloadable applications and built-in services. We are considering both web applications and native applications (OSP, or potentially other native app framwork). There are also few other use cases that can be achieved
with little extra effort:
- provide policy for app-to-app communication, e.g. a notion of custom privileges provided by an application and used by another one. DataControl API in Tizen 2 was a thing that could benefit from such feature. But it never provided a proper policy support, there is only one coarse privilege
http://tizen.org/privilege/datacontrol.consumer.
- limit access of built-in, preinstalled applications. This would require running them with separate Smack labels. It would work for applications that are already implemented as clients of built-in services.


One common factor for all considered Cynara use cases is the User domain. It is supposed to enforce policy per user, per application and per privilege.

>  I’m inferring this from statements like
>
> “The application, we'll call it A, is downloaded and installed at the user's request”
>
> “In my current understanding, Cynara is targeted at web apps which run inside a controlled environment already (the web runtime) and can only access the host through these services”
>
> “That's the whole reason that we need Cynara, so that the abstract "privileges" these apps are required to be allowed can be managed.”
>
> “> I still wonder whether we can apply the same concepts and mechanisms
>
> > for app store apps also to system apps. Let's ignore that for now, though.
>
>  
>
> Of course we can. The biggest problem is that it would require changing programs that we're getting from the community, and we don't generally want to change them (for a number of reasons) if we can avoid it..”
>
>  
>
>  
>
> As you can see I am attempting to decipher conversation that leads me to a perspective on what is in/out of Cynara scope in the absence of an explicit statement describing this.
>
> What I am missing is an express statement as to what Cynara is focused on servicing and what it is not.
>
>  
>
> I ventured over to Jira - https://bugs.tizen.org/jira/browse/PTF-198 - and get this “Services that are being used by applications need to control if the caller has sufficient privileges to call each API.”, which is reaffirmed in the Cynara wiki. The terminology “application” in this context is
> ambiguous – it could mean exclusively downloadable we apps, or also additionally mean what Patrick calls “System Apps”.
>
>  
>
> If I understand the Smack Three Domain model, it identifies a “User domain is comprised of the services that interact directly with the person using the Tizen system and the data those services maintain”.
>
> If I apply my understanding to the terminology on the Cynara thread, I could infer that the project is exclusively focused on servicing Downloadable web applications that use this user domain – correct?
>


More information about the Dev mailing list