[Dev] crosswalk API permission design document, which is out of date and only for reference (RE: enforcing priviliges of web apps)

Zhang, Xu U xu.u.zhang at intel.com
Tue May 20 11:28:59 GMT 2014


Hi all,

Because design document for crosswalk API permission control is not shared to public, I create a wiki https://wiki.tizen.org/wiki/Crosswalk:API_Permission_Control for your reference. The design has been out of date, so I only copy part of contents from original design document. But the wiki has shown mainly thoughts and user cases which can help you understand how crosswalk to check permission API originally.

Best Regards
Zhang Xu

> -----Original Message-----
> From: Zhang, Xu U
> Sent: Thursday, May 15, 2014 4:55 PM
> To: Patrick Ohly; Jussi Laako
> Cc: dev at lists.tizen.org
> Subject: RE: [Dev] enforcing priviliges of web apps
> 
> 
> 
> > -----Original Message-----
> > From: Dev [mailto:dev-bounces at lists.tizen.org] On Behalf Of Patrick
> > Ohly
> > Sent: Wednesday, May 14, 2014 11:02 PM
> > To: Jussi Laako
> > Cc: dev at lists.tizen.org
> > Subject: Re: [Dev] enforcing priviliges of web apps
> >
> > On Wed, 2014-05-14 at 17:41 +0300, Jussi Laako wrote:
> > > On 14.5.2014 17:06, Patrick Ohly wrote:
> > > > The problem remains that the current D-Bus mechanism does not
> > > > allow passing this extra information.
> > >
> > > We just included appctx as part of our dbus API.
> >
> > That works because you have full control over the D-Bus API. It does
> > not work when trying to add access control to an existing API, because
> > it would break the API for apps already using it.
> >
> > At the moment, the patched dbus-daemon will tell clients when (and
> > only
> > when) they ask what the application context of a certain peer is (via
> > GetConnectionSmackContext). This information is not part of the
> > message itself. I don't know how extensible the on-the-wire D-Bus message
> format is.
> > Perhaps it would be possible to extend the header such that the extra
> > information can be added without affecting parsing by D-Bus clients
> > which are not aware of this extension.
> >
> > This does not address the file access issues pointed out by Rafał,
> > which IMHO is the bigger issue.
> >
> > My feeling at the moment is that several interested bystanders (me
> > included) speculate about how Crosswalk could be secured, but do we
> > have the actual decision makers and implementers involved, too? Who
> > owns security of the web runtime?
> [Zhang Xu ] Patrick, Bai (who has left Intel) and I have designed crosswalk API
> permission control. The doc is here
> https://docs.google.com/a/intel.com/document/d/137u_gxmNaIFwVzaCkCFBJ
> yveIdZxuAydWOkMI8oWgD0/edit
> and the implementation is done. I am informed that all web device APIs
> implementation should use Cynara’s service API directly. So the design will be
> dropped from web runtime side.
> I will implement crosswalk runtime security issues.
> >
> > --
> > 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.
> >
> >
> >
> > _______________________________________________
> > Dev mailing list
> > Dev at lists.tizen.org
> > https://lists.tizen.org/listinfo/dev


More information about the Dev mailing list