On Sun, 30 Nov 2014 21:41:45 +0000 "Schaufler, Casey" <[email protected]> said:
> > -----Original Message----- > > From: Puustinen, Ismo > > Sent: Thursday, November 27, 2014 12:42 AM > > To: Schaufler, Casey > > Cc: [email protected]; [email protected] > > Subject: Re: [Dev] [RFC] AUL UI request for multi-process applications > > (ICO/Crosswalk...) > > > > Hi Casey, > > > > In IVI domain the car manufacturers may want to place "regulations" that > > limit the applications that can be shown on the screen in different car > > use cases. For instance: > > > > * When the car is moving, applications that play video are not allowed > > on the screen. > > * When the car is in reverse gear, the application that shows reverse > > camera video must be shown on the screen. > > * When the car is not moving, all applications are allowed on the > > screen. > > > > You can easily think up a large number of possible use cases such as > > these ones. > > > > It's "easy" to enforce similar audio policies since we have a pretty > > good idea who is playing audio to PulseAudio. > > Having a "pretty good idea" is not secure. > > > In order to do such screen > > policy enforcement (even in collaborative way, when the application is > > announcing it's true capabilities in the manifest file) we have to > > somehow know which surface belongs to which application. > > Identifying the application making a request is easy, that's what we > have Cynara for. from what i see here... the app advertises what kind fo app it is. be it in manifest or on the window... does it much matter? i don't see this as a security thing as such... just a matter of "playing nice". > What is a "surface", and who manages surfaces? > In this discussion I see the terms "window", "surface" and "screen". > Are they the same? Are they related? Are they controlled by the > same service? Who is ultimately responsible for making the decision? window and surface are the same. screen ay show one or more surfaces ... maybe overlapping, maybe not. compositor/wm decide on how to show thse. these processes just see windows/surfaces. > > Ismo > > > > > > On Wed, 2014-11-26 at 17:00 +0000, Schaufler, Casey wrote: > > > Why does the package name get used to determine if a window gets > > > displayed? What policy do you really want to enforce? There has got to > > > be a less convoluted way to get what you want than this. > > > > > > > > > > > > > > > > > > From: Dev [mailto:[email protected]] On Behalf Of Manuel > > > Bachmann > > > Sent: Wednesday, November 26, 2014 5:10 AM > > > To: [email protected] > > > Subject: [Dev] [RFC] AUL UI request for multi-process applications > > > (ICO/Crosswalk...) > > > > > > > > > > > > > > > Hi folks, > > > > > > > > > This RFC is about bug TC-1691, TC-159... > > > > > > > > > > > > > > > > > > (The problem happens with Crosswalk today, but it could happen with > > > any other application) > > > > > > > > > AUL provide somes function calls, like "aul_app_get_pkgname_bypid > > > ()", which permit to get the application package name associated with > > > a running PID. > > > > > > > > > Under IVI, the ICO Homescreen (profile/ivi/ico-uxf-homescreen) uses > > > these calls to determine if it should show a window, by getting the > > > PID of its process, and then comparing it will the package name. If if > > > does not match, the window stays hidden. > > > > > > The problem is : > > > > > > > > > In Crosswalk, the process which creates the window (the GPU process) > > > is *not* the same that the one (the browser process) which registers > > > itself as a Tizen application. > > > > > > > > > Crosswalk has a dedicated process for UI operations, which is > > > different of the one that does the application logic. > > > So, the name is never found, and Web applications never show. > > > > > > > > > > > > > > > > > > In this respect, we need a way for an application to "pass" its > > > application identifier to the graphical layer (in this case, ICO).Here > > > are 2 options : > > > > > > 1) in Crosswalk itself, have a package name passed from application > > > layer to the UI/GPU one (won't probably be upstream). Then, have a > > > Weston plugin "receive" and store the information. When requested by > > > the "aul_app_get_pkgname_bypid ()" call, AUL will also request the > > > plugin for this information and respond. > > > > > > > > > Requires modifications in : 3 packages (crosswalk, weston, aul-1) > > > > > > > > > > > > > > > > > > 2) in Crosswalk itself, have a package name passed from application > > > layer to the UI/GPU one (won't probably be upstream). Then, store this > > > data in a local database or specific tmpfs. When requested by the > > > "aul_app_get_pkgname_bypid ()" call, AUL will also request this base > > > or tmpfs for this information and respond. > > > > > > > > > Requires modification in : 2 packages (crosswalk, aul-1) > > > > > > > > > > > > > > > > > > The 2nd idea modifies less packages but may be trickier to implement. > > > Any opinion on this ? > > > > > > > > > > > > > > > -- > > > > > > Regards, > > > > > > Manuel BACHMANN > > > Tizen Project > > > VANNES-FR > > > > > > > > > _______________________________________________ > > > Dev mailing list > > > [email protected] > > > https://lists.tizen.org/listinfo/dev > > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev > -- Carsten Haitzler (The Rasterman) <[email protected]> _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
