On Wed, 26 Nov 2014 17:00:56 +0000 "Schaufler, Casey" <[email protected]> said:
> 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. it's also hardly secure. at least for native apps and x11. apps voluntarily themselves place a PID property on the window (well ok - the toolkit does), and they could fake any PID they wanted by changing it. it's a "nicety" to set this to make things go more smoothly. it is hardly something to use for securing anything. sure - crosswalk itself is a runtime and is enforcing security so this can't be circumvented there - but in the general case it can be. wayland is also another matter - you could focibly query the socket fd for the pid of the other end on the compositor side (and compositor then enforces policy/security), though i smell a race condition here between getting pid of fd, process is closed and replaced by another one, pid recycled... classic security hole. you should be querying the client on the other side DIRECTLY - be able to query smack labels or security relevant info straight from that. not via some indirect lookup that has race condition written all over it. ... oh and since the pid of the gpu process is separate and maybe shared between apps... you will have to fake PID on the GPU process... if that is how you want to enforce security policies... and if you can fake a PID... youa re back to the x11 case above - not something you can use for any security/policy handling at all. don't bother using pid then - make it all co-operative and "hope everyone plays nice". so why are you using pid or package name to make any decisions at all? > 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 -- Carsten Haitzler (The Rasterman) <[email protected]> _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
