> -----Original Message----- > From: Carsten Haitzler [mailto:[email protected]] > Sent: Monday, December 01, 2014 4:05 AM > To: Schaufler, Casey > Cc: Puustinen, Ismo; [email protected] > Subject: Re: [Dev] [RFC] AUL UI request for multi-process applications > (ICO/Crosswalk...) > > 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".
Yes, I believe that it does. The application installer reads the manifest and applies some policy regarding the integrity of the application based on signatures (or lack thereof) within the manifest. The value and worthiness of the signature mechanism is a separate discussion. The application of that policy is done by trusted components of the system. The installer also assigns information that Cynara will use to identify the application. This information can be considered reliable. Information provided by the application about itself cannot be trusted. Ever. You can't count on an application to "play 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. Then the compositor needs to enforce policy (whatever it may be). > > > 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
