> -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Jussi Laako > Sent: Thursday, October 10, 2013 9:22 AM > To: [email protected] > Subject: Re: [Dev] Tizen 3.0 proposal for applications launch > > On 10.10.2013 19:03, Schaufler, Casey wrote: > > You can't. The whole notion of using a daemon in this way is a non-starter. > > Your premise on how to accomplish your goal is flawed. It won't work. > Your plan > > might be convenient if it was based on a system that worked the way > you're asking > it to, but it does not. > > > > You need a different approach to launching applications. > > Hammering on the design you've proposed is not going to result in a > functional system. > > For starters I would like to understand why this launcher thingie needs to run > as root in first place? Why not just a normal session bus service without need > to worry about getting uids or gids right?
Good question. One of our requirements is for application isolation. Somewhere along the line we quit assigning responsibility to people using applications and started assigning it to the application itself. We now want to ensure that applications don't interfere with each other, regardless of how the user might want to use them. To accomplish application isolation you need to invoke a security mechanism of some kind. Android uses UIDs. Tizen uses Smack labels. In any case, you're going to have to set a security attribute. That is going to require privilege. We have kernel based mechanisms (e.g. setuid bit, SMACK64EXEC attribute, SELinux context) to provide setting security attributes for application binaries. Unfortunately, there is a perception that the exec() processing is too slow (I have yet to see numbers to back this up, but "everyone knows" this is the case) so it is standard practice to implement application launchers to speed the process up. The application launcher has to do everything that the exec() call does. That includes setting security attributes. As noted above, this requires privilege. The easy and, to my mind correct, solution is to let the kernel take care of setting the security attributes and throw out the whole "launcher" thing. I have *never* been presented evidence that launchers actually improve performance in the final deployed configuration. But, that's a separate argument. > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
